Skip to content

Netplan api iterator #306

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

Merged
merged 2 commits into from
Jan 3, 2023
Merged

Conversation

Image for: Conversation
Copy link
Contributor

Description

Image for: Description

The Netplan state iterator API is intended to enable consumers to walk through the ordered list of network definitions. It is useful, for instance, when you need to save the netdefs to files but you don't know the netdef ID to lookup for it.

The idea of having a non-opaque struct exposed to consumers was borrowed from Glib (here and here). By doing this, the iterator can be placed at the stack, which is much more convenient.

This API was integrated and tested with the NetworkManager+Netplan integration code base.

Checklist

Image for: 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.
The new NetplanStateIterator struct keeps the iterator state
(basically the front of the netdefs_ordered list) and
netplan_state_iterator_next() will return the next netdef in the list
and update the iterator to point to the next netdef.

Sometimes it is useful to iterate through netdefs, specially when you
don't know the netdef ID. One first consumer for this API would probably
be the NetworkManager + Netplan integration. When NetworkManager loads
the keyfile to the netplan state, we might don't know if the netdef ID
is the interface name or the NM-<UUID> string. With this API we don't
need to know, we can just get the first netdef in the list. As the new
Netplan API doesn't expose internal structures, some API like this one
is necessary.
In order to enable consumers to place the interator at the stack, the
type can't be an opaque struct. The idea is based on glib's
implementation of iterators.

Also, use some glib helpers for simplicity and clarity when accessing
GList elements.
Copy link
Collaborator

slyon left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!
I think this is a useful addition to our API, instead of accessing the internal netdefs HashTable/Map datastructure directly, as has been done previously in such cases.

slyon merged commit 7de9726 into canonical:main Jan 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants