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