* Martin Vidner <[email protected]> [Aug 12. 2009 15:53]: > 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. > > http://mschmidkunz.110mb.com/network.html 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: [email protected] For additional commands, e-mail: [email protected]
