Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
[yast-devel] Some thoughts about modeling
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Tue, 18 Aug 2009 13:50:00 +0200
  • Message-id: <20090818115000.GA24999@xxxxxxxxxxxxx>

the recent discussions about the network model enticed me to share
some thoughts about modeling with you.

There are two approaches to modeling, bottom-up or top-down. Bottom-up
here means starting with a blank sheet of paper and design as it fits
the requirements. With top-down, I'm referring to starting with an
existing model, stripping and refactoring it until it fits.

Both approaches have their pros and cons, neither is 'right' or
'wrong' per-se. It all depends.

And modeling is hard, sometimes very hard if you have widely spread
requirements. Grasping the result can be equaly hard, esp. if the
requirements which led to the model are not known.

In this situation, doing the bottom-up approach is the easiest and
most rewarding as it leads quickly to a result matching current
requirements. However, one has to be very aware of the limitations and
that extending the model to fit additional needs might be very hard or
even impossible.

About two years ago, the Open Management Consortium
(, offline since months) was formed to unify
the various open source system management approaches. Founding members
included the 'big four', namely Zenoss, Hyperic, GroundWorks, and
openQRM. Their initial goal was to agree on a protocol and eventually a
single client daemon.

So they organized a BarCamp and discussed protocols and models. Someone
even showed a presentation bragging about how useless and bloated CIM
was. Understandable, knowing that their main focus was on monitoring.
Their collaboration approach never resulted in any concrete project. The
Open Management Consortium seems to have dissolved in the meantime, I
haven't seen any traffic on the mailing list for months.

But there's more to system management than just monitoring. A lot
more. If the monitoring console shows something red, you want to
manage it (restart, re-configure, update, ...) and bring it back to
green. If a network router failed, you need to know where it is
(physically), what services the outage affects, and how to order a
replacement unit.

All this is covered in a CIM model. It tries to encompass all
requirements of system management, which are many. (ITIL,,
gives a nice glimpse into this whole area.)

And CIM is a fully normalized model, which is not really helping to
make it easily understandable. But its helping to make it flexible and
useful for a lot of use cases.
(For the curious, here is a nice introduction into CIM modeling:

Its interesting to note that all major computing vendors build their
management solutions on top of the CIM model. Microsoft, IBM, Dell,
HP, Sun, Intel, Cisco, Apple, just to name a few.

Now how does all this apply to WebYaST ?

Going the easy path of bottom-up is acceptable, if the limitations and
consequences for future extensions are known and documented. Its also
harder to reuse upstream work. As WebYaST grows and implements more
functionality, such a (self-designed) model might quickly reach its

Going the harder path of top-down will be more work up front but make
it easier in the future to extend it and reuse upstream work. If
WebYaST is successful, requirements will come to support discovery,
inventory, root cause analysis, more network types, routing, etc. All
this is already taken care of in the CIM model, we could be standing
on the shoulders of giants.

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 >
This Thread
  • No further messages