* Michal Zugec <[email protected]> [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: [email protected]
For additional commands, e-mail: [email protected]
