Changing the network model

[imobachgs]

Problem

Agama's network model is heavily inspired by nmstate. Connections are represented by an enum and each variant contains a struct which depends on the type (e.g., the WirelessConnection struct). Those structs have a base field that points to a BaseConnection struct which holds the common fields for all connection types.

And that's perfectly fine. However, we decided to introduce some methods to hide the fact that the common information lives in a separate struct. We could say it is for encapsulation reasons, but I don't know whether it is a good idea. Even we created some getters and setters for those fields, adding quite some boilerplate code

Additionally, until we introduced the ConnectionBuilder (in #885), creating a new connection with some custom data (like an id and a UUID) was not straightforward because you needed to make the BaseConnection first (see this example.

Proposal

Although I am not 100% sure whether it is a better idea, I am exploring the possibility of using a simpler layout to represent a connection. In this case, we would use a single struct containing the common fields plus a config field for specific stuff. That field contains an enum which represents each kind of connection.

/// Represents an availble network connection
#[derive(Debug, Default, Clone)]
pub struct Connection {
    pub id: String,
    pub uuid: Uuid,
    pub mac_address: MacAddress,
    pub ip_config: IpConfig,
    pub status: Status,
    pub interface: String,
    pub match_config: MatchConfig,
    pub config: ConnectionConfig,
}

#[derive(Default, Debug, PartialEq, Clone)]
pub enum ConnectionConfig {
    #[default]
    Ethernet,
    Wireless(WirelessConfig),
    Loopback,
    Dummy,
}

And not getters/setters as they are not needed at all.

Testing

• Adapted the unit tested.

[coveralls]

coverage: 74.724% (+0.008%) from 74.716%
when pulling 15087be on imobachgs:refactor-network-model
into 05a339b on openSUSE:master.

[cfconrad]

Not sure if it is a problem at all. This function show the case that we now easily transform a Connection from one type into the other, by setting the config enum. Before it was like, collecting common settings + specific settings and then construct the Connection.

But currently I do not see a problem with it. For me this approach has benefits over the current.

[imobachgs]

Yes, I have the same opinion and it does not look like a problem (at least by now). I think this approach is simpler. But I will work on this once the bonding support is finally merged.

[teclator]

LGTM