Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] WebYaST: Network REST Model v1
  • From: Michal Zugec <mzugec@xxxxxxx>
  • Date: Thu, 13 Aug 2009 16:07:19 +0200
  • Message-id: <4A841E17.2080502@xxxxxxx>
Klaus Kaempf wrote / napísal(a):
* 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.


Hm, we already have sysconfig names. But I can understand CIM requirement.

* /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.

This UI is visualisation of network requirement - just to imagine what
we're going to configure, nothing else.


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 ?


Device is physical hardware. It can exists without configuration.
Interface is software representation of physical device or virtual
device. Virtual devices are software-created. Without configuration,
they disappears after "rcnetwork restart"


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.

Right, it makes sense


* /network/configs/ (RO)

Configs are separated from devices


Can you document the purpose of configs in more detail ?

It's configuration of Layer3 of the ISO/OSI model. Devices defines
Layer2 of the ISO/OSI model.


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 ?


Yes


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 the future, this can be usefull. For wireless devices you can switch
between several APs just by associate different configurations to one
device.


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.


No, it represents
/etc/sysconfig/network/config.NETCONFIG_DNS_STATIC_SEARCHLIST


* /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').

But in this case, there's nothing in common ...


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' ?

No, there's no network-yapi yet




Thanks !

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)


Bye,
Michal

--
Best Regards,
Michal Zugec
Software developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: mzugec@xxxxxxx
Lihovarska 1060/12 tel: +420 284 028 960
190 00 Praha 9 fax: +420 296 542 374
Czech Republic http://www.suse.cz/

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups