Replace IP Generation Code

date:

2017-1-11 22:00

tags:

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.

Problem description

The current IP generation code is difficult to maintain, despite mostly being moved into a separate ip.py 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.

Proposed change

An initial draft of new IP management code has been written in the IPManager class.

After that, the existing get_ip_address, and set_used_ips were 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.

Alternatives

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.

Playbook/Role impact

No noticeable impact on the playbooks and roles should be seen; this is largely facilitating code maintenance and should produce the same output.

Upgrade impact

There should be no upgrade impact - the IPManager class should be loaded with the already-generated IP addresses in upgraded installations.

Security impact

This change should not affect any sensitive data. It is unrelated to secret storage.

Performance impact

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 profiled.

End user impact

This change would be invisible to users of the deployed cloud.

Deployer impact

No configuration or output changes should be introduced. The current configurations should be used as-is.

Developer impact

This should improve quality of life for developers debugging the IP generation behavior.

Dependencies

This has no direct dependencies on other blueprints or specs.

Implementation

Assignee(s)

Primary assignee:

nolan-brubaker, IRC: palendae

Other contributors:

steve-lewis, IRC: stevelle

Please add IRC nicknames where applicable.

Work items

  • 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.

Testing

Unit and integration tests should be added for all code changes to confirm there are no regressions.

Documentation impact

Developer documentation should be updated to reflect the new mechanism used, preferably included with implementation patches.

References

N/A