Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] WebYaST: Network REST Model v1
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Fri, 14 Aug 2009 10:17:52 +0200
  • Message-id: <20090814081751.GF4645@xxxxxxxxxxxxx>
* Michal Zugec <mzugec@xxxxxxx> [Aug 14. 2009 09:55]:
Klaus Kaempf wrote / napísal(a):

Ok, understood. But it doesn't answer my question. Let me restate it:
If interfaces and devices all show up below /network/devices/, how do
I know which is which ? I'd rather not have to retrieve every instance
and check a property.

Hm, you don't need to know that.

Actually, I'd challenge this. But lets wait for feedback from beta
customers. I think the physical/virtual distinction can be added later.

No question about the usefulness. Just focus on the simple parts (one
config per interface) now and extend later.

Hm, but here's conflict of requirements. As I understand from Jiri, we
should define rest-api not only for this simple purpose but also for
future. We need to discuss this ...

You can spend an indefinite amount of time trying to get an API
'right' and you'll still find cases where its 'wrong' later.

So you have to be prepared to refactor and extend later anyways.

Looking at the amount of work in front of us and the schedule, I'd
rather keep it simple for now and extend later as we get more

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

Ok, understood. Then please name it accordingly, 'resolver' is confusing.

CIM property is CIM_DNSGeneralSettingData.DNSSuffixesToAppend, so
DNSGeneralSettingData/DNSSuffixesToAppend ? I will write this in the
next mail.

Not quite. I was arguing about the 'resolver' name in the URI of
'/network/resolver', where both the sysconfig and the CIM model talk
about 'dns'. So lets follow upstream naming conventions.

BRIDGE_PORTS='eth0 eth1'

* /network/devices/1
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 ...

Startmode ? bootproto ? Some property for 'virtual' device ?

No! This properties are for Layer3 - not /devices/ but /configs/

Ah, now we're getting closer. The above example confused me since
ifcfg-br0 is a config whereas /network/devices/1 is a device. However,
the device properties (above) duplicate the config values (brigde*).

So imho it should be
config=/network/configs/br0 (-> pointing to ifcfg-br0 properties)

(The properties of /network/devices/br0 should reflect ifconfig
output, showing the current values of the interface).

One question remains: Is all this covered by the current YaST 'yapi' ?
No, there's no network-yapi yet

So how are you going to implement the network rest-service then ?

For first iteration we can use CLI backend and then write yapi

What does 'write yapi' include ? A wrapper to existing YCP network code
or a reimplementation ?

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 >