Allow to set ipv4.may-fail / ipv6.may-fail

[Hoeze]

Hi, I am trying to setup a persistent bridge with networkmanager but the bridge connection gets deactivated once it fails to configure IPv4. Networkmanager allows to set "ipv4.may-fail" and "ipv6.may-fail" to keep the connection up even when the ip configuration fails. Is it possible to set these options with this role? If not, would it be possible to add these options?

[Hoeze]

I just realized that this is the wrong setting to change. What I actually would need to keep the device up is setting connection.autoconnect-retries=0.

[liangwen12year]

In NetworkManager, ipv4.may-fail allows the connection to remain active even if it fails to configure an IP address (e.g., if IPv4 configuration fails). When may-fail is set to yes, NetworkManager will not deactivate the connection due to IP configuration failure. If your goal is to keep the bridge connection active even when IPv4 fails, setting may-fail to yes is the more appropriate solution. If you need NetworkManager to keep retrying until it successfully configures IPv4, you can use autoconnect-retries with an appropriate value. We can support the connection.autoconnect-retries in the network role, I will implement it asap, but if you would like to implement this feature, patch is welcomed.

[liangwen12year]

The PR for supporting autoconnect_retries is https://github.com/linux-system-roles/network/pull/737 .

[Hoeze]

Amazing! Thanks a lot @liangwen12year :tada: Given your previous answer, it would then make sense to have ipv4.may-fail=yes and autoconnect_retries=0, if I want to keep the connection up until it obtains an IP, right?

[liangwen12year]

@Hoeze , ipv4.may-fail=yes tells NetworkManager that the connection should still be considered "up" even if it fails to configure IPv4. In your situation, I honestly think that it would then make sense to have ipv4.may-fail=no and autoconnect_retries=0.

[Hoeze]

Oh, I see, then I misunderstood this option. Thank you for the explanation.

Would you be able to also support the ipv[4|6].may-fail option in this role?

[liangwen12year]

yes, I can support it. By the way, ipv[4|6].may-fail is already supported in network_state variable but autoconnect-retries setting is not supported in network_state variable. But the backend of network_state variable- nmstate has the mechanism for retrying to apply the desired state a few times before giving up when encountering the applying failure.

[liangwen12year]

The property in network_state variable corresponds to may-fail: no is wait-ip, the setting can be set to the following options:

     * "any": System will consider interface activated when any IP stack is
              configured(neither static or automatic).
     * "ipv4": System will wait IPv4 been configured.
     * "ipv6": System will wait IPv6 been configured.
     * "ipv4+ipv6": System will wait both IPv4 and IPv6 been configured.

Here is an example:

network_state:
  interfaces:
    - name: eth1
      type: ethernet
      state: up
      wait-ip: ipv4+ipv6
      ipv4:
        enabled: true
        dhcp: true
        auto-dns: true
        auto-gateway: true
        auto-routes: true
      ipv6:
        enabled: true
        dhcp: true
        autoconf: true
        auto-dns: true
        auto-gateway: true
        auto-routes: true

@Hoeze , can you try out the network_state variable? I think that this already fulfill your needs by configuring wait-ip proprety.

[liangwen12year]

@Hoeze , this is the PR for may fail support in the network role, https://github.com/linux-system-roles/network/pull/741.

[Hoeze]

Thanks a lot @liangwen12year! It's amazing to have these features so fast available :)

Reguarding your suggestion, I did not have time to test it yet. But #741 makes it unnecessary, right?

[liangwen12year]

Thanks a lot @liangwen12year! It's amazing to have these features so fast available :)

Reguarding your suggestion, I did not have time to test it yet. But #741 makes it unnecessary, right?

Right. you can achieve the similar effect by using the may_fail4 or may_fail6 in the network_connections variable.

[liangwen12year]

The upstream PR is merged. @Hoeze , the new property is wait_ip, we want to have the same syntax as Nmstate. Let us know if the new property works for you.

I want to point out that we are promoting network_state as the future of network management using the network role. Since the backend of network_state is Nmstate, the network_state modules represents the future direction for the network role, aiming to provide a more streamlined and reliable way of managing network. As a result, the focus is on promoting the use of network_state over the network_connections variable to ensure better consistency and functionality moving forward. Additionally, most of the features currently supported in NetworkManager are also available with network_state. For more information and examples on how to configure the network using Nmstate schema in network_state variable, please refer to the official documentation at nmstate.io. For detailed syntax and explanations of each parameter, visit nmstate's API documentation.