Copia de NMISx and opCore

Today we had a discussion about these two technologies and how they will be used going forward.

This will be a point form list of things that came up:

NMISx

• NMISx will likely become the data loader, it will be given a mode (one of a list something like this: LNT/mixed/Nodes.pm/Pure DB) and possibly a db handle and using this it will load a node with the proper config/summary/info/etc data
  • this will give it the option to override data from different areas (like apply nodeconf), it will keep the knowledge about where the data came from at a high level and not buried inside of node internals
  • Maybe provide option like NMISx::SaveNode(nodeObj)
• The node structure will stay mostly the same:
  • Node
    • Config
    • Info
    • Nodeconf
    • Summary
    • Summary8/16 (these might go away? become redirect? not sure how that would work with opcore accessing directly and opHA)
      • Interesting to note that Summary data is basically a copy of data found in Info so it may go away, Summary8/16 may also be calculated on the fly, depends how opHA will work.
• Nodes.pm kinda/sort-of falls into the Node->Config section but it also has knowledge about the where the data should go (like how to save it). NMISx can use it to load data and embellish the Node->Config data with this info. It will then be available via opCore using dot notation.  The saving functionality could possibly be put into NMISx or NMISx::Nodes
• Interface will be special and stored separately, NMISx::Node will probably provide a way to view it's interfaces
• NMIS Code will continue to access these areas of a node via a function/interface so the data can be moved to a seperate collection if needed.

opCore

• Provides search functionality, way for apps to get list of nodes and query specific info about them, NMISx does not provide this currently.
• currently when showing a node index it instantiates a new node and runs the query against each, NMISx provides the data loading, opCore breaks down the dot notation and accesses an NMISx::Node object appropriately to get the data
• opCore will possibly be:
  • a layer on-top of NMISx that will either use NMISx for providing it's functionality 
  • or will go directly to the data if it's in mongo, as the dot notation could/should directly translate to Mongo
• if direct access via dot notation is broken  NMISx  will probably  be used to fill in the functionality blank (as it is now).
• 2 new functions should be added to opCore:
  • index interfaces
  • show interface
• it may be obvious but it's not totally clear how the interactions here work.  the data is sort of the interface when going direct to db, going via NMISx is cleaner but slower as the queries have to load everything.  if/when nmisx moves/changes the data layout in the db, opCore will have to be adjusted to know this.  can still work, while dereferenceing dot notation if it hits specific spots it can know it needs to switch to different collections or possibly just ask NMISx

Interfaces

• interfaces will go into their own collection, they will refer back to their node via name and/or GUID (tbd), opCore will access directly for now (as we only need search functionality