Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] WebYaST: Network REST Model v1
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Thu, 13 Aug 2009 15:16:16 +0200
  • Message-id: <20090813131616.GA2500@xxxxxxxxxxxxx>
* Martin Vidner <mvidner@xxxxxxx> [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: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References