[yast-devel] WebYaST: Network CIM Model
CIM naming ---------- As you can see, the nice names "configs", "devices", "routes", etc. are gone. Welcome to CIM! 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 :-) 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" (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</> ... </> 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</> </> 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? 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) -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Friday 14 August 2009 17:03:32 Martin Vidner wrote:
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
Yes, I would keep it ruby like so ActiveResource works out of the box.
/NetworkPort/eth0
so this would become network_port/eth0 ? :-) -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* 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
On Mon, Aug 17, 2009 at 02:49:31PM +0200, Klaus Kaempf wrote:
Well, modeling _is_ _hard_. Thats one of the reasons I'd like us to look at existing models instead of inventing our own. [...] 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.
I and Miso have tried to continue with this. It is taking too long, and I think that we face two options: 1) use the CIM model properly (simplified (denormalized) or not). It will take us very long and it will be hard to use 2) use CIM so-so, not to spend too much time on it. If it looks like CIM, some people will be put off by its complexity (actual or reputed). Those who won't will be disappointed by the inaccuracies in our simplifications. So I propose to go ahead with prototyping the non-CIM interface that we sent as v1 (or some small improvement of it). -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Martin Vidner <mvidner@suse.cz> [Aug 17. 2009 16:52]:
On Mon, Aug 17, 2009 at 02:49:31PM +0200, Klaus Kaempf wrote:
Well, modeling _is_ _hard_. Thats one of the reasons I'd like us to look at existing models instead of inventing our own. [...] 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.
I and Miso have tried to continue with this. It is taking too long, and I think that we face two options: 1) use the CIM model properly (simplified (denormalized) or not). It will take us very long and it will be hard to use
Agreed. So use the CIM model as a guidance.
2) use CIM so-so, not to spend too much time on it. If it looks like CIM, some people will be put off by its complexity (actual or reputed). Those who won't will be disappointed by the inaccuracies in our simplifications.
You'll never please everyone ;-)
So I propose to go ahead with prototyping the non-CIM interface that we sent as v1 (or some small improvement of it).
No objections. But try to follow CIM attribute and class names. Please document your findings inside the client module to inform others about the API decisions being taken. 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
participants (3)
-
Duncan Mac-Vicar Prett -
Klaus Kaempf -
Martin Vidner