* Martin Vidner
If you wonder why another model for the same, I have started this in parallel to Miso looking at CIM, and intentionally it does not include any CIM yet.
Next we will look how it can be made more CIM-like and whether the anticipated resulting complication is too much :)
The request for 'CIM-like' is mainly to prevent us from inventing 'new' property or function names. Defining a REST API is essentially modeling the resource, and thats what the CIM model already provides. Just pick what you need.
* /network
No! The URL is generated internally when registering the resource within the rest-service. Just define the 'interface' name below config/resources/network.yml, the rest will be taken care of.
This is a UI proposal and should not influence the resource model too much.
But the network services, including a DHCP *server*, will be outside
Agreed.
Basic Config ------------
* /network/devices/ (RO)
Devices and interfaces are the same for now.
How would I be able to distinguish them ?
Devices are read only (for physial devices, but see below for virtual). The read-write part are the configs.
* /network/devices/1 (RO) interface=eth0 product=MSI 1341
Hmm, why "1" as the id ? The interface name (eth0) should be distinct and can be used as the id.
* /network/configs/ (RO)
Configs are separated from devices
Can you document the purpose of configs in more detail ?
like ifcfg-* (shown here like key-value pairs but xml in fact)
* /network/configs/1 (RW) startmode=dhcp4 * /network/configs/2 bootproto=static ipaddr=1.2.3.4/24 * /network/configs/3 startmode=dhcp4 wireless_essid=HomeWiFi wireless_key=HomeSweetHome * /network/configs/4 startmode=dhcp4 wireless_essid=WorkWiFi wireless_wpa_psk=HomeSweetHome
In the above form, configs are not associated with devices and it works like in NetworkManager, a call like /network/devices/1/configure?config=/network/configs/42 is needed.
Hmm, if the configs are completely separated from interfaces, passing the complete path (network/configs/42) makes sense. But since they are related to network, passing the config id should be sufficient, no ?
But a config can get another attribute, "device" that makes it the default config for a device, and it works like our ifcfg (where "device" is in the filename)
Don't over-engineer it ! Nothing in the feature request asks for the separation of device and its config.
For simplicity, the UI can hide the device-config separation and always edit the single config for a device.
Yes, focus on a single config for now.
* /network/devices/1/current-config (RO) (current_config? TODO style) ipaddr=1.2.3.4/24
Why 'current-config' ? Retrieving the resource instance (i.e. /network/devices/eth0 should get you all instance properties; similar to calling 'ifconfig eth0'.
This distinguishes the config, which can specify the IP or say DHCP from the current-config, which always specifies the IP (or does not exist). Think /etc versus "ip" output.
* /network/routes/ * /network/routes/default (RW) <route> <via>1.2.3.4 ("ip r" keyword) <route>
What about multiple default routes ?
* /network/resolver (RW) <nameservers> <nameserver>1.2.3.4 <nameserver>1.2.3.42 <searches> <search>example.com <search>example.net
(use-dhcp ?)
Hmm, I'd assume /network/resolver to represent /etc/resolv.conf, right ? However, /etc/resolv.conf is autogenerated, so /network/resolver should be 'RO'. /etc/resolv.conf doesn't record anything about how it was generated, i.e. via dhcp or manual setup. Thus 'use-dhcp' is a (RW) config property, not a resolver property.
* /network/resolver/current-config (RO) Like with the devices, this shows the config even if /network/resolver says DHCP
* /network/hostname (RW) hostname=trikolka domain=suse.cz fqdn=trikolka.suse.cz
Why 'fqdn' ? Are there cases where fqdn isn't a concatenation of hostname and domain ?
(dhcp??)
No, not for /network/hostname. "set hostname via dhcp" is a property of the network device config since it determines which interface sets the hostname via dhcp.
Virtual Devices ---------------
(This is for the future, included here just to show that the API accomodates them)
For virtual devices (special interfaces not based on hardware devices - bridge, bonding, vlan) is sysconfig configuration splitted into device and configuration parts. /network/configs stays the same and /network/devices becomes writable (details to be worked out but the REST paths are unchanged from the basic config)
bridge ------ ifcfg-br0 STARTMODE='auto' BOOTPROTO='dhcp' BRIDGE='yes' BRIDGE_PORTS='eth0 eth1' BRIDGE_PORTPRIORITIES='50 20'
* /network/devices/1 interface=br0 bridge='yes' bridge_ports='eth0 eth1' bridge_portpriorities='50 20'
Hehe, here the object oriented model of CIM shows its value. A physical and a virtual network device should be based on a common parent class. Thus documenting the properties of the virtual device should only show the subclass ('VirtualDevice'). For bridge_ports, don't name interfaces but RESTful pathes (i.e. bridge_ports = [ /network/devices/eth0, /network/devices/eth1 ]) See "A closer look at REST" (http://kkaempf.blogspot.com/2009/04/yast-opensuse-installation-and.html) and "REST APIs must be hypertext-driven" (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven) for the reasoning.
* /network/configs/1 bootproto='dhcp'
VLAN ---- ifcfg-vlan3 STARTMODE=onboot ETHERDEVICE=eth0 IPADDR=192.168.3.27/24
* /network/devices/1 interface=vlan3 etherdevice=eth0 # /network/devices/10 * /network/configs/1 ipaddr=192.168.3.27/24
The same applies as above.
bonding ------- ifcfg-bond0 STARTMODE='onboot' BOOTPROTO='static' IPADDR='192.168.0.1/24'
BONDING_MASTER='yes' BONDING_SLAVE_0='eth0' BONDING_SLAVE_1='eth1' BONDING_MODULE_OPTS='mode=1' # backup mode
* /network/devices/1 interface=bond0 bonding_master='yes' bonding_slave_0='eth0' # /network/devices/10 bonding_slave_1='eth1' # /network/devices/11 bonding_module_opts='mode=1' # backup mode * /network/configs/1 ipaddr='192.168.0.1/24'
One question remains: Is all this covered by the current YaST 'yapi' ? Thanks ! Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org