Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New submodule for state manipulation #379

Merged
merged 6 commits into from
Jul 25, 2023

Conversation

daniloegea
Copy link
Collaborator

@daniloegea daniloegea commented Jul 11, 2023

Description

It moves the code that collects and aggregates system's and netplan's network configuration to a submodule called state. It's intended to be used by netplan commands that requires configuration manipulation such as netplan status and netplan get.

The motivation for that is to add the logic for netplan status --diff (or netplan diff) in the same submodule in the near future. So the manipulation of the state will be all in the same place.

It's organized in 2 classes:

SystemConfigState: responsible for collecting and storing the current system networking configuration. It's currently used by netplan status. The code is essentially the same from netplan status.

NetplanConfigState: responsible for collecting and storing the current Netplan configuration. It's currently used by netplan get.

It also adds an iterator that returns the IP addresses present in a netdef. The idea is to add more getters for other properties that will be used by netplan diff.

Checklist

  • Runs make check successfully.
  • Retains 100% code coverage (make check-coverage).
  • New/changed keys in YAML format are documented.
  • (Optional) Adds example YAML for new feature.
  • (Optional) Closes an open bug in Launchpad.

@slyon
Copy link
Collaborator

slyon commented Jul 12, 2023

+1 I very much like the approach. Having all state manipulation in a common (private) Python module should help to ease maintenance, going forward.

I also like the fact that you're refactoring before implementing new functionality! Thanks.

@daniloegea daniloegea marked this pull request as ready for review July 14, 2023 08:44
@daniloegea daniloegea requested a review from slyon July 14, 2023 08:47
@daniloegea
Copy link
Collaborator Author

The DebCI failure seems unrelated.

Copy link
Collaborator

@slyon slyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much! As stated above, I like the refactoring a lot. Having all data handling inside a central module is very useful. Then, using very simple code inside the views (get.py / status.py) to access this data (read only) and display it in the relevant format.

I've put a bunch of inline comments, two of which are especially important:

  • class NetdefInterface vs configmanager.py
  • {Netplan,System}ConfigState[Data] class harmonization

netplan/cli/state.py Outdated Show resolved Hide resolved
tests/cli/test_state.py Outdated Show resolved Hide resolved
netplan/cli/commands/get.py Outdated Show resolved Hide resolved
netplan/cli/commands/get.py Show resolved Hide resolved
netplan/cli/commands/status.py Outdated Show resolved Hide resolved
netplan/cli/commands/status.py Outdated Show resolved Hide resolved
netplan/cli/state.py Outdated Show resolved Hide resolved
netplan/cli/state.py Outdated Show resolved Hide resolved
netplan/cli/state.py Outdated Show resolved Hide resolved
netplan/cli/state.py Outdated Show resolved Hide resolved
@daniloegea daniloegea marked this pull request as draft July 18, 2023 13:36
@daniloegea daniloegea force-pushed the netplan_diff_round1 branch 3 times, most recently from a52fc7e to 42487af Compare July 18, 2023 16:40
@daniloegea daniloegea marked this pull request as ready for review July 18, 2023 17:41
@daniloegea
Copy link
Collaborator Author

Thanks, Lukas. I tried to address all your comments.

I got rid of the *ConfigStateData and NetdefInterface classes.

I also add an interface to iterate over the IP addresses present in a netdef. The idea is to add all the interfaces that will be used by netplan diff. With this there is no need for a new class to store this information.

@daniloegea
Copy link
Collaborator Author

Not sure why tests are failing on Fedora... it works locally...

@daniloegea daniloegea requested a review from slyon July 18, 2023 17:51
Copy link
Collaborator

@slyon slyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much, Danilo! This is looking very clean now.
I put some (non-blocking) nitpicks as inline comments. But as this is all still internal code (not exported through any API or binding), we can still change the names or implementation details in the future, if you want to merge it as-is.

We should investigate the RHEL/Rocky and Fedora tests failures, though. They seem to pass in the main branch, so are probably related to the changes in this PR.

Edit: The RPM failures are potentially related to RPM's make check call not using the proper libnetplan.so (maybe we need some LD_LIBRARY_PATH quirks, so it can pick up the new iterator)

netplan/libnetplan.py Outdated Show resolved Hide resolved
src/util.c Outdated Show resolved Hide resolved
netplan/libnetplan.py Outdated Show resolved Hide resolved
state.py is responsible for collecting and storing the network
configuration. It will also be responsible for detecting differences
between the system's and netplan configuration in the future.

The main motivation for this new submodule is the centralization of
state management.
The code used by "netplan status" to read and aggregate the system's
network configuration and the code used by "netplan get" to read the
Netplan's configuration was moved to this module.
Make use of the new module to read the configuration used by "netplan
get" and "netplan status".
@daniloegea daniloegea force-pushed the netplan_diff_round1 branch 2 times, most recently from cbdb64d to 31ded93 Compare July 20, 2023 12:49
@daniloegea
Copy link
Collaborator Author

I changed the iterator implementation to return all the IPs from netdef.ip4_addresses, netdef.ip6.addresses and netdef.address_options. To standardize the return value, the return type is NetplanAddressOptions*. The iterator in the Python code must call free_address_options() on each item after instantiating the new NetplanAddress class contains all the properties (address, lifetime and label) of each address.

@daniloegea daniloegea requested a review from slyon July 20, 2023 14:13
src/util.c Outdated Show resolved Hide resolved
It enables us to retrieve the list of IPs, (V4 and V6) from a given
netdef via Python bindings.

The same iterator will consume the ip4_addresses, ip6_addresses and
address_options (where IPs with options are stored).

Each item returned by the _next() function is a NetplanAddressOptions*,
even for addresses without options. Each object is released when the
next one is requested.
@daniloegea
Copy link
Collaborator Author

daniloegea commented Jul 24, 2023

I changed the iterator implementation to free objects as new ones are produced. Now the caller doesn't need to do that, destroying the iterator should be enough to release all the memory.

Copy link
Collaborator

@slyon slyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, lgtm!
praise: I like how you implemented the AddressIterator to automatically free the memory it doesn't need anymore, making it transparent to the (Python) caller.

Two tiny suggestions inline, but feel free to merge as-is if you feel like.

src/util.c Show resolved Hide resolved
src/util.c Show resolved Hide resolved
@daniloegea daniloegea merged commit a0b0fc3 into canonical:main Jul 25, 2023
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants