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

update netdog to a more recent version of the toml library #3422

Closed
webern opened this issue Sep 6, 2023 · 7 comments
Closed

update netdog to a more recent version of the toml library #3422

webern opened this issue Sep 6, 2023 · 7 comments
Labels
area/core Issues core to the OS (variant independent) status/research This issue is being researched type/bug Something isn't working

Comments

@webern
Copy link
Member

webern commented Sep 6, 2023

Netdog cannot be easily upgraded to newer versions of the toml library because the feature perserve_order no longer exists in newer versions of toml. When I tried removing the cargo feature and updating it to 0.7, a few tests failed.

@webern webern added type/bug Something isn't working status/needs-triage Pending triage or re-evaluation labels Sep 6, 2023
@webern webern mentioned this issue Sep 6, 2023
1 task
@stmcginnis stmcginnis added status/research This issue is being researched area/core Issues core to the OS (variant independent) and removed status/needs-triage Pending triage or re-evaluation labels Sep 13, 2023
@markusboehme
Copy link
Member

I wasn't immediately sure why order mattered, so documenting what I found in the code:

#[derive(Debug, Deserialize)]
pub(crate) struct NetConfigV1 {
    // Use an IndexMap to preserve the order of the devices defined in the net.toml.  The TOML
    // library supports this through a feature making use of IndexMap.  Order is important because
    // we use the first device in the list as the primary device if the `primary` key isn't set for
    // any of the devices.

@markusboehme
Copy link
Member

On a brief look I couldn't find the preserve_order feature of toml being removed. I updated the lib and produced a metal-dev build that passes the unit tests. I can send a PR for that. There's a bunch of other dogs that use the old version of toml. @webern Do you know why those might have been kept back?

@webern
Copy link
Member Author

webern commented Jan 8, 2024

I think that is fine. I think if unit tests are passing for all variants the we should be good. Net.toml is well tested and also the code has been worked on a fair amount since I opened this issue. If the tests are passing now then it would seem the behavior is fine.

Do you know why those might have been kept back?

I think it is because we have a weird lint that makes us feel like using two versions of a library is a bad thing. I'm not a fan of the lint (in cargo-deny).

@markusboehme
Copy link
Member

markusboehme commented Jan 8, 2024

Do you know why those might have been kept back?

I think it is because we have a weird lint that makes us feel like using two versions of a library is a bad thing. I'm not a fan of the lint (in cargo-deny).

I may be misunderstanding you, but I'm not sure this would be the reason--there's already two different versions of the crate in use.

@yeazelm
Copy link
Contributor

yeazelm commented Jan 8, 2024

Currently we do conditional compilation for netdog and I'm not confident we run all unit tests right now automatically that might catch this. One can run them manually to ensure this is working as expected by passing different backend options with something similar to VARIANT=metal-dev SYSTEMD_NETWORKD=1 cargo test vs VARIANT=metal-dev SYSTEMD_NETWORKD=0 cargo test from the sources/api/netdog directory to ensure all the tests are run when testing this update. Order is really important here for the primary interface and we will break users if this changes behavior so its worth being a little extra cautious while we bump this.

@markusboehme
Copy link
Member

The build bot should run all unit tests on PR submission: It runs across all variants, and the build does include a cargo make unit-tests. The variants shipping k8s 1.28 set the systemd-networkd feature flag.

Personally, I think the "first interface is primary unless explicitly specified" is a bit of a misfeature, but one we're stuck with. At least the requirement for ordering is documented in the code (see first comment).

@webern
Copy link
Member Author

webern commented Mar 22, 2024

Closed by #3830

@webern webern closed this as completed Mar 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/core Issues core to the OS (variant independent) status/research This issue is being researched type/bug Something isn't working
Projects
Development

No branches or pull requests

4 participants