Replace IP Generation Code¶
inventory, ip, networking
The current inventory code uses a simple set to manage assigned IPs
USED_IPS) and complex queues to pull from the available subnets.
This code can be simplified and made more modular.
- Launchpad blueprint:
The current IP generation code is tightly couple to the configuration loading, writing, and inventory manipulation code. To help provide better, more focused test coverage, this code can be updated and replaced.
The current IP generation code is difficult to maintain, despite mostly being
moved into a separate
module. The code uses the external
Queue class, which is slightly more
complex than necessary. The
USED_IPS set and the pools of available IPs
are not managed together, and could easily become out-of-sync.
New code has been written to add an IPManager class, but it is not currently integrated into any other code. Such integration is a somewhat large task, and would be error-prone to do in a single review. This spec is intended to serve as a road map to guide small, focused changes towards using it.
Note that while the IPManager includes an API for external IPAM systems, this spec is only focused on using this class within the code, not on any sort of plugin system.
An initial draft of new IP management code has been written in the IPManager class.
After that, the existing
refactored to still use the existing data structures, but in a way that
would allow usage of the new IPManager class. See review 403915.
Some refactors may be necessary for the IPManager class to facilitate this and further codify assumptions.
The code be left as is, with the assumption that it will be replaced wholesale by some other system in the near future. That replacement might happen via plugins or a new inventory codebase. This has not been deeply explored in the context of the IP management/generation.
One such replacement system, for example, could be using LXD to entirely manage container creation, which is where IP generation is primarily used.
No noticeable impact on the playbooks and roles should be seen; this is largely facilitating code maintenance and should produce the same output.
There should be no upgrade impact - the IPManager class should be loaded with the already-generated IP addresses in upgraded installations.
This change should not affect any sensitive data. It is unrelated to secret storage.
Generating IPs may be slightly faster, since this approach doesn’t rely on
delayed access from
Queue objects. However, the overall runtime of the
inventory is negligible in the overall speed of the system and hasn’t been
End user impact¶
This change would be invisible to users of the deployed cloud.
No configuration or output changes should be introduced. The current configurations should be used as-is.
This should improve quality of life for developers debugging the IP generation behavior.
This has no direct dependencies on other blueprints or specs.
- Primary assignee:
nolan-brubaker, IRC: palendae
- Other contributors:
steve-lewis, IRC: stevelle
Please add IRC nicknames where applicable.
Refactor current IP loading/management functions to be amenable to replacing the data structures.
Replace the data structures and update the objects being passed between functions.
Unit and integration tests should be added for all code changes to confirm there are no regressions.
Developer documentation should be updated to reflect the new mechanism used, preferably included with implementation patches.