We have a large development team which are developing nagios checks -- they have their own Nconf instance in which they test/prove the nagios checks they are developing.

Is there any way to take there configs/items and import them into another Nconf instance?

right now the only way to do this is by hand, we have to manually duplicate everything they do in their Nconf instance with our global production instance

Perhaps another way would be some sort of granular user ACL control where a "dev" user can only create/modify/delete specific host(s) and then an "admin/manager" must approve those changes before they can be deployed.

Hi. Yes, you're right. When exporting and re-importing using nagios cfg or CSV, some of the NConf-specific information is lost.The tricky part when merging two NConf instances is how to resolve conflicts that arise from item names being uses twice, duplicate checkcommands etc...

Writing a script to merge two instances requires some time. Also, the perl-API needs to be extended to allow modifying and deleting existing entries.

It would be a great feature to have, but right now I have very little time to invest in it...

*one*If you *always* make changes to the "dev" instance and then want to "push" those changes to a "production" instance, you could probably just use simple database commands, maybe even some sort of replication setup where replication is stopped by default, and you start it to push changes and then stop it again. Then you should be able to refresh the NConf GUI on the prod side, generate and deploy.

*two*If you have two (or more) completely separate instances that are each managed independently (i.e. all the ID's would be different) that you want to merge, it still wouldn't be that hard to just do it at the database level. Making a backup before you started obviously? It might get a little messy if there are multiple items with the same name that are configured differently, but thats just a matter of setting precedence, whichever has the highest priority wins (copied first). If an item of the same name already exist, skip it, right??

*three*Item level Export/Import, versus merging entire instances, would also be nice. For example, it would be really nice if we could export/import a specific template, checkcommand, etc. from one instance to another. I would envision a mechanism that allowed for an export from the various "Show" screens, with an import button at the bottom? Another idea would be a multi-item export from the "Show Host parent / child view" screen, so that you would export all the dependencies necessary from the chosen level down. The import is really where things get tricky, but you could have a simple "overwrite" or "skip" option for the initial version, simply based on "name"?