>
> I guess I'm at the right place to post, but tell please me if it's not the
> case.
>
I'll suggest that perhaps the dev list might be a better choice since (if
I'm understanding your intent correctly) you're looking for development
feedback on creating new functionality. Of course, it could also be argued
that this is more of a Zenoss Enhancement Proposal (ZEP) rather than a topic
for discussion, but it doesn't really matter. :)
>
> I 've seen a couple of emails in this forum on how to use/extend Zenoss as a
> full CMDB solution, but it's still unclear to me if Zenoss is a good platform
> to build a full CMDB, at least the way it's meant to be in ITIL. I understand
> that Zenoss may not have been designed initially for that purpose, but it's
> growing well and maybe also in this direction...
>
I actually haven't gone through the latest ITIL iteration, so please correct
me if you have better information. :)
It's more than a little unclear (at least to me! :) first of all what one
really needs from a CMDB in the first place. Everyone wants it to "do the
right thing the way that I mean it", but that's a little hard to build a
product around. The statement "a CMDB is an asset database with relationships"
is fine as far as it goes, but how do you manage the modeling of the
relationships?
For instance, how do you record (assuming that this is indeed important to
you -- another unresolved issue to be decided on a case-by-case basis) the
relationship of a fibre channel cable (everyone has a naming convention for
their cables, right? :) to the SAN disk subsystem + FC switch on one end, and a
dual-port HBA attached to a virtualization layer (eg AIX VIO server) to a
logical partition (eg LPAR or VMWare image) that is used by a database which in
turn is used by an application used by your user community? And since the
answer to the question really depends on how you model redundancy (at all
layers) and whether or not the application made it to your service catalogue
and has an SLA (among other things :), all sorts of practical thorny issues
arise.
I'll suggest that the CIM models, while complex at first sight, might be a
good candidate for tackling the technical modelling issue. The policies
surround move / add/ change in software will also be interesting (you know, the
"OWWW! My brain hurts!" type of interesting :)
And how would you manage to keep all of that info up to date, with as much
automation as possible?
I think that a CMDB is a great idea, but before implementing something like
this, I think that there should be a little more discussion surrounding the
scope and feature list. After the spec, maybe a prototype and on to
usefulness! :)
kells[/quote]
-------------------- m2f --------------------
Read this topic online here:
http://community.zenoss.com/forums/viewtopic.php?p=13564#13564
-------------------- m2f --------------------
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
