Add ability to create custom relationships between objects of the same type.

[scetron]

Environment

• Python version: 3.x latest
• Nautobot version: 1.0.0b2 (latest)

Proposed Functionality

Extend the custom relationship feature to be able to create relationships of the same object type. EG. between dcim.device and dcim.device.

Use Case

This would allow to create a simpler type of Virtual Chassis or perhaps a custom relationship for Cisco FEX devices. There may be other creative uses by removing this limitation.

Database Changes

Unsure.

External Dependencies

There should not be any external dependencies.

[jedelman8]

This has already come up a few times. Will definitely require some exploratory efforts here

The use case we've heard already was FEX devices, but would love to hear if there are other use cases, even beyond virtual chassis.

[bryanward-net]

The ability to relate Sites to Sites could help with #230 . Similarly, I'd love to have VLAN Groups be able to inherit from each other so that VLANs that span several "sites" or "buildings" can be made available to all interfaces within a site/building.

[cmacnevin]

Agree, nested sites is a long term request of ours which never got traction. But if we can associate prefixes with any object - eg rack groups or regions, then it's not so important to us.

[ggidofalvy-tc]

Chiming in on this feature request, this would also open up the possibilities for point-to-multipoint and multipoint-to-multipoint connectivity, if one could define custom connectivity between interfaces. Probably better suited for a generalized multipoint circuit model, but this could be another approach to modelling the outlined scenario.

[glennmatthews]

Updating this issue with some of the concerns raised in #846:

Directionality

• In some cases a same-to-same relationship is implicitly directional (parent->child, etc.):
  • Cisco FEX
  • Virtual-chassis-like scenarios
  • Spine-leaf device relationships
  • etc.
  • Note that in the above examples, parent and child (source and destination) are mutually exclusive (see also "Mutual exclusivity", below), and the relationship definition should logically include source and destination filters by device model or device role such that the set of valid "source" devices" is non-overlapping with the set of valid "destination" devices.
  • However, there may also be cases where the relationship is directional but a given record can participate as both a source and as a destination (think "trees" and "linked lists" as concepts) -- TODO though, can we think of real-world use cases for Relationships that match this pattern?
• In other cases a same-to-same relationship is implicitly non-directional (think Circuit A/Z sides)
  • multipoint-to-multipoint connectivity
  • HSRP/VRRP device pairs
  • etc.

We probably need a design that can support both directional and non-directional relations. This may require defining additional types of Relationship ("one-to-one-nondirectional", ...?) or perhaps just adding a "directional" flag to the Relationship model - details TBD.

Mutual exclusivity of source/destination

In some types of same-to-same relationship, (particularly non-directional one-to-one relations, but possibly others as well) adding a relationship association in which a record is the "source" should prohibit creation of a different relationship association in which the same record is the "destination" (i.e, Device A (source) <--> Device B (destination) association should prevent creation of Device C (source) <--> Device A (destination) or Device B (source) <--> Device C (destination)). This behavior might be implied by the type of relationship specified, or it might need to be another separate field on the Relationship definition - more investigation is needed here.

GraphQL representation

Additionally, the current GraphQL implementation of RelationshipAssociation rendering simply uses the relationship name (rel_my_relationship_name) and doesn't provide any indication of which "side" of the relationship is being represented. This is a non-issue when the two sides are different data models as there's no ambiguity in this case, but:

• for directional same-to-same relationships, it's necessary to be able to distinguish which side of the relation is being represented
• for same-to-same one-to-many relationships, the two sides have different cardinality (single object versus set of objects) and this would need to be accounted for in the GraphQL schema

[glennmatthews]

Based on the best information we have so far, all of the concrete use cases we have examined for same-to-same relationships fall into the "mutually exclusive" category, so for at least the time being, we will not be supporting the option for an object to act as both source and destination for the same Relationship.

[glennmatthews]

Implemented in next (1.2.0) by #846