Skip to content

New submodule for state manipulation - #379

Merged
daniloegea merged 6 commits into
canonical:mainfrom
daniloegea:netplan_diff_round1
Jul 25, 2023
Merged

New submodule for state manipulation#379
daniloegea merged 6 commits into
canonical:mainfrom
daniloegea:netplan_diff_round1

Conversation

@daniloegea

@daniloegea daniloegea commented Jul 11, 2023

Copy link
Copy Markdown
Contributor

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

slyon commented Jul 12, 2023

Copy link
Copy Markdown
Contributor

+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 force-pushed the netplan_diff_round1 branch from 0a89a85 to ff55faa Compare July 13, 2023 16:55
@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
Copy Markdown
Contributor Author

The DebCI failure seems unrelated.

@slyon slyon left a comment

Copy link
Copy Markdown
Contributor

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

Comment thread netplan/cli/state.py Outdated
Comment thread tests/cli/test_state.py Outdated
Comment thread netplan/cli/commands/get.py Outdated
Comment thread netplan/cli/commands/get.py
Comment thread netplan/cli/commands/status.py Outdated
Comment thread netplan/cli/commands/status.py Outdated
Comment thread netplan/cli/state.py Outdated
Comment thread netplan/cli/state.py Outdated
Comment thread netplan/cli/state.py Outdated
Comment thread netplan/cli/state.py Outdated
@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
Copy Markdown
Contributor 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
Copy Markdown
Contributor Author

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

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

@slyon slyon left a comment

Copy link
Copy Markdown
Contributor

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)

Comment thread netplan/libnetplan.py Outdated
Comment thread src/util.c Outdated
Comment thread netplan/libnetplan.py Outdated
Danilo Egea Gondolfo added 5 commits July 20, 2023 09:46
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
Copy Markdown
Contributor 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
Comment thread src/util.c Outdated
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
daniloegea force-pushed the netplan_diff_round1 branch from 31ded93 to 338782b Compare July 24, 2023 10:45
@daniloegea

daniloegea commented Jul 24, 2023

Copy link
Copy Markdown
Contributor Author

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.

@slyon slyon left a comment

Copy link
Copy Markdown
Contributor

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.

Comment thread src/util.c
Comment thread src/util.c
@daniloegea
daniloegea merged commit a0b0fc3 into canonical:main Jul 25, 2023
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