I've read up all replies that have been posted until now after your =
request
for comments and I've found them interesting.
Although they help a lot while taking the final decision, I would like =
to
add a consideration to the "obsolescency" factor.
My contribute is an idea to let modules to became less obsolete as new
versions of nagios are released.
The approach of versioning I think it is the only straight way you have =
to
check for module compatibility... but is it really necessary to discard =
a
module if you, for example, add new data without changing the meaning of =
the
existing one?
Take this example:
service structure of v1.1 is N bytes long with M variables inside.
In version v1.2 you add a variable (M+1) of 4 bytes (N+4) to the =
structure
appending it after the last variable in the service structure. A daily
scenario for a project like nagios, isn't it?
Well, referring to what =the
others are saying, now you have to update the "structure" version, or =
the
"API" version or simply the nagios version to make the check for modules
compatibility.
You have two paths to follow to check the compatibility of an old =
module:
1) Deny access to the new nagios structures
2) Try to accomodate the "older" module to make it feel comfortable =
using
the new nagios version.
The point 2 is not always easy or fatigueless to implement but it can =
save a
lot of recompiling/upgrading issues to the nagios community (mainly for
production sites). The great impact on modules during an upgrade would =
be
reduced and it will give some time to system administrators to get the
updated modules (which cannot be available at that moment). The urgency =
to
have the last version installed may be very important (bug fixes, =
security
holes, list your own motive, etc).
The point 1 may be the only reply in case of major structure changes... =
but
this is another story
However, let's get back to the implementation details:
I suggest a compatibility mode API that remaps API calls to old ones and
casts new structures to old ones.
Example
-------
struct service **services; /* Global and already populated */
struct service_v11 /* old 1.1 structure */
{
... PREVIOUS VERSION VARS ...
};
struct service /* new 1.2 structure */
{
... PREVIOUS VERSION VARS ...
long created_by; /* NEW: Pointer to the contact who has added this =
service
to the host */
};
// API Function example to retrieve service number N
struct service *getService(unsigned long number)
{
if(MODULE_VER =3D=3D 11)
return (struct service_v11 *) services[number]; /* Cast the new
structure to the old one */
else /* Here you can put more checks for older versions too, just
decide the backward compatibility level you want to achieve
return services[number]; /* The module is aligned with our =
version,
return the actual structure */
}
I'm sure this is a too simplistic example to cover all cases but is only =
to
explain the bare concept.
In addition to this, if the module has to write back the structure to =
nagios
memory I suggest to use an "Update" callback function rather than =
letting
the user write the updated data directly to nagios memory possibly =
messing
up things.
You can do sanity checks and even remap old structures with default =
values
for variables not directly handled by older structures, using the above
technique (ie. putService(); ).
This problem reminds me the old problem to copy data to clients or =
giving
them direct access.
It is an implementation choice that, as always, has pros and cons. If =
you
provide an access function to data you have to return copied data to the
modules and put it back with another access function. This is slow but =
more
robust. If you provide direct access to data structures it will be fast, =
but
a minimal error can make nagios crash in a very bad way.
Of course the majority of modules will only read data, but who knows... =
Any way the choice of the "registration" method it is up to you (ie. =
what
the module has to do to inform nagios about the version he handles): you
already h
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]