* Michal Zugec <mzugec@suse.cz> [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 experience.
[...]
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
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 ------ 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 ...
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 /network/devices/br0 config=/network/configs/br0 (-> pointing to ifcfg-br0 properties) ip=.... netmask=... (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 ? 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