Add models for intended operational state

jedelman8 commented 2 years ago

As ...

Nelly - Network Engineer

I want ...

to be able to store the intended operational state of the network in Nautobot. (This is not actual performing discovery or operational validation. Just storing absolutes, thresholds, and ranges) (multiple personas can be used for this)

So that ...

I can use this data to populate verification and intent-checks in my observability platforms, and then use SSoT (or equivalent) to compare/contrast the intended operational state rules. These should be abstract models that define the targets such as qty neighbors, neighbor statuses, ranges of available light levels, qty of prefixes and routes, interface drop ranges, etc. The list can go on.

I know this is done when...

I'm able to populate the intended operational state of a variety of models. I'm sure this could be added/embedded into feature models so configure + oper are tied together like OpenConfig, but I wanted to open this to get a discussion going and feedback.

To clarify, if someone is using Python or Ansible for basic health checks, they would query intended state (such as qty neighbors from Nautobot) and then use that to compare it against how many are active. If it's a more robust solution, these standards in Nautobot can drive the "rules" in commercial assurance and observability platforms.

There should be a main view for visualizing observed state models, but also it should be possible to inject them on detailed views like interfaces.

The final piece would be to store the actual value to know the health, i.e. use SSoT to populate the data after humans define the approved ranges, etc. It'd be a win to store the desired thresholds and rules first, and following that, to populate the actuals, to see the operational health next to the intended state.

Optional - Feature groups this request pertains to.

[X] Automation
[ ] Circuits
[X] DCIM
[ ] IPAM
[X] Misc (including Data Sources)
[ ] Organization
[X] Plugins (and other Extensibility)
[ ] Security (Secrets, etc)
[ ] Image Management
[ ] UI/UX
[ ] Documentation
[ ] Other (not directly a platform feature)

Database Changes

Not sure. This may be core (for base and common oper state) and plugins for others, but doesn't matter, as long as it becomes possible.

External Dependencies

No response

bryanculver commented 2 years ago

Let's evaluate why the combination of custom/computed fields, config contexts, custom relationships, dynamic groups don't solve this problem. Are we short documentation? Do any of the features above not go far enough? Is there hesitation because of the data sprawl potential with some of these features that being able to scope narrowly enough.

jedelman8 commented 2 years ago

On the surface those can be clearly be used for anything. IMO, it's no different than building actual data models for config data. because we want them as first-class citizens (via core, plugins, or a series of both like secrets) and because they are relevant for horizonal 80%+ use cases.

glennmatthews commented 2 years ago

From my perspective, the question is, are these new data models or are they simply new fields on existing data models? To my mind it's the latter (fields on the Device and Interface models, most likely) but if there's a need for actual first-class data models for intended state, separate from the Device and Interface models, I'd like to more clearly understand the requirements behind that.

nautobot / nautobot