This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

NPM/NCM, why are there two different nodes tables?

After doing a ton of work to group our 550+ network devices in NPM, I had to go back and redo it in NCM. Luckily I was able to do an alter table command however it seems very silly to keep node information in two separate tables in two separate databases.

Any goals to collapse the two separate products into a single database by just adding the additional tables when NCM is installed?

  • Node management integration (perhaps not single DB) is definitely on the roadmap.   The reason for separate DBs today is that NPM and NCM have traditionally been sold both as standalone products.  We've recently begun providing more and more integration as customers like yourself have asked for both monitoring and config management to be available from a single pane of glass.  

    One thing we've done in NCM 5.x that you may not be aware of is we've added an Orion NPM import job to NCM (Schedule > Create New Job > Import devices from Orion database).   This way you only have to make the changes once in NPM and then they will synchronize on a schedule you define.

    HTH,

  • One thing we've done in NCM 5.x that you may not be aware of is we've added an Orion NPM import job to NCM (Schedule > Create New Job > Import devices from Orion database).   This way you only have to make the changes once in NPM and then they will synchronize on a schedule you define.

    Chris, are you able to check (and possibly help) the situation with my case 91668 (IIRC...)? We are still having data integrity problems in this scheduled import process you describe.

    Markku

  • Markku, I apologize.  I didn't realize that you were the one that reported that issue with manually set transfer settings being changed on import.   We've reproduced this in QA and we're looking at whether we can fix this in 5.5.1.

  • Thanks Chris for confirmation on this issue. I wonder why the support case was closed without any communication with me on the issue.

    Anyway, hopefully a fix will be available (public or private) as soon as possible.

    Also, as a feature request for this import job, I'd really like to see possibility to use SNMP community as a selection criteria for importing nodes (now it is only possibly to use Vendor and Machine Type properties and "EnableNCMImport" custom property for selecting the nodes for import). Was there a feature request forum somewhere... :-)

    Markku

  • Chris, just to make it sure: Have you noticed that also devices usernames and passwords are "defaulted" as well in the import process (just like the transfer settings)?

    Markku

  • Thanks mleinio.  We've got that one as well.



  • Markku, I apologize.  I didn't realize that you were the one that reported that issue with manually set transfer settings being changed on import.   We've reproduced this in QA and we're looking at whether we can fix this in 5.5.1.



    Chris, realizing this is a pretty recent thread, but this Node Import functionality is one I've been looking for, for quite some time (a little less than a year).

    Basically, I want NCM to synchronize the nodes from NPM, nightly would work, but it has to be clean.  As it is, the general node import process on NCM isn't quite as clean as NPM, I'd like it to all get rolled into one process.  This would follow along with the suggestion I made quite a while back to make the custom property data population a part of the node import process.  That feature is the only thing that made me start using the web interface to add nodes!

    I also need to reiterate how important a unified database for all products is, the "two products under one web front-end" thing is getting old, so much data and work is redundant between the two.  Even simple stuff like custom properties.

    So, in all of the above, there hasn't really been a question.  The questions are:

    1)  How soon do you guys expect to be ready to release 5.5.1, making the workaround to the two-database system functional for ongoing maintenance?

    2)  How far down the roadmap is one database to rule them all, one database to bind them?

    These are, relatively obvious questions, I would think.

    Peter

  • 1)  How soon do you guys expect to be ready to release 5.5.1, making the workaround to the two-database system functional for ongoing maintenance?

    5.5.1 is currently in testing so we're targeting before the end of this month.

    2)  How far down the roadmap is one database to rule them all, one database to bind them?

    Centralized node management and permissions across NPM/NCM is on our roadmap for the first half of 2010.   This isn't a trivial change, so there will be changes with each version to get us there.   In the interim, it's important to note that were very committed to ensuring that the Orion node import job is a viable workaround.