u/s patch https://github.com/nmstate/nmstate/pull/1892

It is unclear what this property related to network __state__ . This is determine NM specific action on activation only.

If we would add this into nmstate, we need use case why this is needed.

The behaviour is the one specified here https://bugzilla.redhat.com/show_bug.cgi?id=2082042#c2, that script is creating a ovs-bridge on top of the primary nic doing a clone of mac address.

The enforced behaviour is specified here https://github.com/openshift/machine-config-operator/pull/2929

"When activating the br-ex connection, NM would return success if only
one of the address families got an IP. We should wait for both families
in the case of dualstack."

So is needed for this use case, don't know if we can make it implicit at nmstate somehow instead of make it explicit at the scheme.

I am considering to introduce a backend specific configurations allowing arbitrary setting to this interface.

For example:

```yml
---
interfaces:
  - name: eth1
    type: ethernet
    networkmanager:
      connection.id: WAN
      ipv4.may-fail: no
```

I am coding on a demo so that user can add/override any settings after nmstate.

(In reply to Gris Ge from comment #4)

> ```yml
> ---
> interfaces:
>   - name: eth1
>     type: ethernet
>     networkmanager:
>       connection.id: WAN
>       ipv4.may-fail: no
> ```

Since we are discussing to improve the situation in NM, it seems wrong to me to expose the API that needs improvement, directly.
IMHO this feature also requires clarity on the user stories, use cases etc regarding profile failures. Then the possibilities that make sense should be exposed in a sensible way in Nmstate.

The user would block the network connection activation for DHCPv4 or v6 on next OS boot up not the time when he/she call `nmstatectl apply`.

This is a future behaviour of NetworkManager, not final backend-neutral desire network state .

Hi Quique,

I have created a demo PR: https://github.com/nmstate/nmstate/pull/1902 
Could you take a look to see whether it fit your needs?

Hi Till,

In above demo PR, the `connection.id` is also considered as NetworkManager specific terminology which is not share-understanding of other network backends (e.g. systemd-network, wicked, netplan).

Patch posted to upstream: https://github.com/nmstate/nmstate/pull/1902


Example yaml:

```yaml
---
interfaces:
  - name: eth1
    type: ethernet
    backend-specific:
      networkmanager:
        ipv4.may-fail: False
        ipv6.may-fail: False
    ipv4:
      enabled: true
      dhcp: true
    ipv6:
      enabled: true
      dhcp: true
      autoconf: true

```

New patch send to upstream: https://github.com/nmstate/nmstate/pull/1967



This is the example yaml to force NM wait on both IP stack:

```yaml
---
interfaces:
  - name: eth1
    type: ethernet
    state: up
    mtu: 1500
    wait-ip: ipv4+ipv6
    ipv4:
      enabled: true
      dhcp: true
      auto-dns: true
      auto-gateway: true
      auto-routes: true
      auto-route-table-id: 0
    ipv6:
      enabled: true
      dhcp: true
      autoconf: true
      auto-dns: true
      auto-gateway: true
      auto-routes: true
      auto-route-table-id: 0
```

The possible `wait-ip` values are: any, ipv4, ipv6, ipv4+ipv6.

Verified with:
nmstate-2.1.3-1.el9.x86_64
NetworkManager-1.39.12-1.el9.x86_64

The value of `wait-ip`:
any  -->  both `ipv4.may-fail` and `ipv6.may-fail` in NM connection are set to yes
ipv4 -->  `ipv6.may-fail` is set to yes
ipv6 -->  `ipv4.may-fail` is set to yes
ipv4+ipv6 --> both `ipv4.may-fail` and `ipv6.may-fail` are set to no

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nmstate bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7991