Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] WebYaST: Network CIM Model
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Mon, 17 Aug 2009 14:49:31 +0200
  • Message-id: <20090817124931.GI29397@xxxxxxxxxxxxx>
* Martin Vidner <mvidner@xxxxxxx> [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

Yeah, thats confusing at first sight but widely accepted and

(hierarchy: EthernetPort: NetworkPort: LogicalPort: LogicalDevice:
EnabledLogicalElement: LogicalElement: ManagedSystemElement: ManagedElement)


<!-- LogicalDevice -->
<DeviceID>eth0</> <!-- key -->
<!-- NetworkPort -->
<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
<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:

<AddressOrigin value="4">DHCP</> <!-- "Static",
"DHCP", "BOOTP", "IPv4 Link Local", "DHCPv6",
"IPv6AutoConfig" -->

<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)

<AddressOrigin value='4'>DHCP</>

<AddressOrigin value='3'>Static</>
<GatewayIPv4Address></> <!-- default route -->

(WiFi is too new (Jun 2009):

the Association ElementSettingData connects ManagedElement and SettingData
(compare NetworkManager's ActiveConnection)

<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.


resolver (DNS client) configuration

<AddressOrigin value='3'>Static</>
<DNSServerAddresses type='array'> <!-- CIM: string[] -->

<AddressOrigin value='3'>Static</>
<AppendParentSuffixes type="boolean">true</>
<DNSSuffixesToAppend type="array">

(BTW it seems that netconfig does not enable dissassociating AddressOrigin
for these two)

<AddressOrigin value='4'>DHCP</>

<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
( was fine,
just adapt the class and attribute names (to whats used in CIM) and use
REST pathes for the dependencies.

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups