* Martin Vidner <mvidner@suse.cz> [Aug 14. 2009 17:03]:
CIM naming ----------
As you can see, the nice names "configs", "devices", "routes", etc. are gone. Welcome to CIM!
Beauty is in the eye of the beholder. ;-)
WORK-IN-PROGRESS: the REST aspect is not covered now, because the way CIM composes the data using subclassed associations makes it hard to figure out, and below are only guesses. A Confusingly Irritating Model :-)
Well, modeling _is_ _hard_. Thats one of the reasons I'd like us to look at existing models instead of inventing our own.
note to XML: - I use the usual ruby attributes like type=array/boolean. - Additionally I use <Foo value='80'>HTTP</> to combine CIM enumerations (Value+ValueMap) - CIM is CamelCase. We may want to adapt_it_to_ruby
CIM_NetworkPort means "network interface", not a "(TCP/IP )protocol port"
Yeah, thats confusing at first sight but widely accepted and standardized.
(hierarchy: EthernetPort: NetworkPort: LogicalPort: LogicalDevice: EnabledLogicalElement: LogicalElement: ManagedSystemElement: ManagedElement)
/NetworkPort/eth0
<EthernetPort> <!-- LogicalDevice --> <DeviceID>eth0</> <!-- key --> <!-- NetworkPort --> <NetworkAddresses> <item>112233445566</> <item>aabbccffeeff</> </> <LinkTechnology value='2'>Ethernet</> <!-- EthernetPort --> <Capabilities type='array'> <item value='3'>WakeOnLan</> </> <EnabledCapabilities type='array' /> <!-- empty --> </>
LogicalDevice has a m:n Realizes association with Core:PhysicalElement, not sure how to model it in REST <PhysicalElement> <Manufacturer>Realtek Semiconductor Co., Ltd.</> <Model>RTL-8169 Gigabit Ethernet</> ... </>
CIM associations refer to 'object pathes', which is simply a URI. Relations between REST model instances are also modeled by URI. The ethernet_port REST model could just have a physical_element attribute containing the (REST) path of the physical instance. (Associations in CIM are stand-alone instances with two object path attributes describing the relation. A fully normalized model.)
IPProtocolEndpoint: Core:ProtocolEndpoint:
<IPProtocolEndpoint> <IPv4Address>1.2.3.4</> <SubnetMask>255.255.255.0</> <AddressOrigin value="4">DHCP</> <!-- "Static", "DHCP", "BOOTP", "IPv4 Link Local", "DHCPv6", "IPv6AutoConfig" --> </>
<IPProtocolEndpoint> <IPv6Address>1:2:3::4</> <PrefixLength>64</> <AddressOrigin value="8">IPv6AutoConfig</> </>
Just merge the endpoint attributes to the logical_device attributes. Having a fully normalized model is nice (and CIM tries to reach this state) but just not appropriate for our current goals.
interface configuration -----------------------
(IPAssignmentSettingData : SettingData: ManagedElement)
/IPAssignmentSettingData/eth0 <IPAssignmentSettingData> <AddressOrigin value='4'>DHCP</> </>
/IPAssignmentSettingData/eth0 <StaticIPAssignmentSettingData> <AddressOrigin value='3'>Static</> <IPv4Address>10.20.30.40</> <SubnetMask>255.255.0.0</> <GatewayIPv4Address>10.20.7.254</> <!-- default route --> </>
(WiFi is too new (Jun 2009): http://www.dmtf.org/standards/published_documents/DSP1088_1.0.0.pdf )
the Association ElementSettingData connects ManagedElement and SettingData (compare NetworkManager's ActiveConnection)
<ElementSettingData> <ManagedElement>/IPProtocolEndpoint/1</> <SettingData>/IPAssignmentSettingData/eth0</> <IsDefault value="1">Is Default</> <!--0:Unknown, 2:Is Not Default --> <IsCurrent value="1">Is Current</> </>
TODO! how is all this bound to /NetworkPort/eth0?
/NetworkPort/eth0 should have an attribute describing the default (preferred) config and another one describing the current config.
SAPSAPDependency? ActiveConnection?
resolver (DNS client) configuration -----------------------------------
(NETCONFIG_DNS_STATIC_SERVERS) /DNSSettingData <DNSSettingData> <AddressOrigin value='3'>Static</> <DNSServerAddresses type='array'> <!-- CIM: string[] --> <item>10.20.0.2</> <item>10.20.0.8</> </> </>
(NETCONFIG_DNS_STATIC_SEARCHLIST) /DNSGeneralSettingData <DNSGeneralSettingData> <AddressOrigin value='3'>Static</> <AppendParentSuffixes type="boolean">true</> <DNSSuffixesToAppend type="array"> <item>suse.cz</> <item>suse.de</> </> </>
(BTW it seems that netconfig does not enable dissassociating AddressOrigin for these two)
/DNSSettingData <DNSSettingData> <AddressOrigin value='4'>DHCP</> </>
/DNSGeneralSettingData <DNSGeneralSettingData> <AddressOrigin value='4'>DHCP</> </>
(TODO: Virtual Devices, in case you haven't had enough)
Try to de-normalize the model, then it will be a lot easier. The initial proposal (http://lists.opensuse.org/yast-devel/2009-08/msg00042.html) was fine, just adapt the class and attribute names (to whats used in CIM) and use REST pathes for the dependencies. 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