Add abstract location model

[jedelman8]

User Stories

As Nelly the Network Engineer,

I want...

• A more flexible way to define locations and hierarchy of locations within Nautobot

So that...

• I can replicate the location structure of my organization and store a variety of network related assets in Nautobot that may not be racked.
• I can store a variety of network related assets in Nautobot that may not be racked (ie. UPS in a room)

I know this is done when...

• Users can assign a "Location" to any other object that references Region and Site today
  • Assigning of Locations is consistent within child/parent relationship (honors existing Site/Region)
• Users can see the new "Location" in the associated object list and detailed views for objects that are linked to the Location

Austin the Network Automation Engineer

I want…

• To provide my own definitions of locations and pattern for location types
• Enforce location hierarchy within my organization

So that…

MVP

• I can custom model my facilities by providing my own set of attributes for Location Types (ie. buildings)
• Location must either be parented by another Location or a Site (breaking change long term Site, Region, RackGroup would become LocationTypes)
• Locations can only have one parent
• Simple content type restriction on LocationType (Devices can only be assigned to a cabinet but not a city)
• I can attach address or any other physical characteristics to my LocationType model
  • Can be implemented via custom fields
  • Will NOT require scoping custom fields down to specific LocationTypes (see: Add support for groups of custom fields #899, Please Provide a Feature to Limit the Scope of Custom Fields #889)
• Objects & locations are expected to validate that they are in the same site, region as their parent
• Mandating custom attributes for specific location types would most likely need to be implemented as a custom validator

Future

• Location must either be parented by another Location or none (Site, Region, RackGroup become LocationTypes)
• Locations can have many parents
• I can enforce my users to populate mandatory attributes for given Types of Locations
• I can enforce my users to use Location Tree of my definition (ie. City -> Building -> Floor -> Room, but never “City -> Room”). Would be nice if I could use custom validators for this to be more flexible.
• Location must either be parented by another Location or a Site (breaking change long term Site, Region, RackGroup would become LocationTypes)
• Config context filtering by location
• Location statuses

I know this is done when...

• I can register my own LocationType via Nautobot plugin
• I can code my own LocationTypes for custom attributes shown in the UI, API, GraphQL
• I can enforce hierarchy
• I can enforce mandatory attributes for specific locations

Questions

• What will the migration strategy be for an eventual forced relationship to a location model

---

Additional Context

For more context, please see #613 and #230

This issue will supersede #613 and #230 (eventually replace) and provide a foundation for a new abstract organizational model. In the short-term, a new location model (that includes location type) is proposed that links to all objects that already link to region and site. Similar to region, this will be an optional attribute users can take advantage to further define the location relationship to other objects.

[jathanism]

I loveeeeee this idea.

Imagine having Site and Region instead be Location(type=LocationType("site")) and Location(type=LocationType("region")), where LocationType("region") could be a parent of LocationType("site"). Objects that link to a Site today, could be linked to a Location tomorrow.

This could open the door for a myriad of custom locations like:

• Region (US-west)
  • Site (LAX)
    • Facility (LAX1)
      • Cluster (LAX1a)
        • Room (LAX1a-CR1)
  • Site (SJC)

etc...

Questions/concerns:

• When we introduce this? Like do we introduce it in v1.x and start providing it as an optional alternative
  • If we do this, do we allow assignment of an object to either a Site/Region OR a Location but not both?
• Should we think about other types of "locations" such as clusters/pods?
  • i.e. What about rack groups or other groupings that represent physical placement of hardware?
• How do we migrate legacy Region/Site/other "location" objects to the new data model once we go all in on it (such as in v2.0.0)? Automatically? Through some kind of guided upgrade process? #YOLO?

[lampwins]

We should probably have a flag or mechanism on a LocationType to designate which types of resources are allowed to be assigned to a location. For instance, as a user I would want to make sure a device cannot be assigned to a LocationType for regions. Prefixes, though, I might allow in this case.

[jedelman8]

When we introduce this? Like do we introduce it in v1.x and start providing it as an optional alternative

Yes.

If we do this, do we allow assignment of an object to either a Site/Region OR a Location but not both?

I would think both for now.

Should we think about other types of "locations" such as clusters/pods?

I'm not following this. As this is proposed now, this would just be wherever there is region/site today, there would now be location. Wouldn't add more to it than that for now.

How do we migrate legacy Region/Site/other "location" objects to the new data model once we go all in on it (such as in v2.0.0)? Automatically? Through some kind of guided upgrade process? #YOLO?

Don't know. But automatically would be the intention. I think it's too early to define that because we don't know what the end-state would be.

We should probably have a flag or mechanism on a LocationType to designate which types of resources are allowed to be assigned to a location. For instance, as a user I would want to make sure a device cannot be assigned to a LocationType for regions. Prefixes, though, I might allow in this case.

This makes sense.

[darcynz]

Any thought about rebranding 'Rack Groups' for this purpose? Many users will be using rack groups in this way currently and seems to achieve the goal with out adding additional models :)

[jvanderaa]

Rebranding brings in other changes that need to happen then, such as updates to Ansible modules. Instead of a rebranding, a new model with a method to migrate may make sense.

[jakubkrysl]

Any thought about rebranding 'Rack Groups' for this purpose? Many users will be using rack groups in this way currently and seems to achieve the goal with out adding additional models :)

I think Rack Groups are only part of proposed Location functionality. There is big overlap on both sides, but it does not cover all the functionality.

For our use case we need to know location of Racks and Devices, but we cannot assign a Device to a Rack Group. The workaround now is to create "group" Rack with size 1 (minimum) for each Rack Group and assign non-racked devices there. This is used for example for storage room (not in production) or for devices not in any rack at all but running in production. This is where Location completely replaces Rack Group. It allows us to physically find the device.

But Rack Groups are still very much usable even when Location is introduced. They provide easy way to see elevation of multiple racks at once. An example where we use this is server room with 6 rows of racks. We have Rack Group for each of the row which allows us to see elevation of just 10 racks instead of 60. Separate Location for each row does not make much sense.

[cmacnevin]

@jedelman8 - is this moving along? We have some pretty serious need for a more flexible model. Eg we want to be able to create locations like 'vpc' and 'room,' and we wan tto be able to assign prefixes to any location object. I think we've discussed this before.

Is there a target version?

[mzbroch]

• Region (US-west)

  • Site (LAX)

    • Facility (LAX1)

      • Cluster (LAX1a)

        • Room (LAX1a-CR1)

  • Site (SJC)

This structure follows our requirement - the model would allow to represent physical location of the device/unit.
Once I agree with majority of the comments here, I'm thinking we should provide some Location types via Core:
LocationType("Rack"), LocationType("Region"), LocationType("Site") so that for the Core provided structures we are able to properly represent them as well.

[jedelman8]

@lampwins can you provide an update on thought process and timing based on @cmacnevin question above?

[netopsengineer]

@itdependsnetworks @jdrew82
This is an important feature for our Service Provider type use cases where Nautobot centers around a Datacenter / Campus model currently, but looking beyond that in a situation where we have hundreds of DC's in multiple States, Cities, Markets, and customer premise gear tied back to those DC's, DC's tied back to other DC's across states in some cases, having more flexibility would be very helpful.

[glennmatthews]

Initial Locations implementation was done by #1891. Known remaining action items:

• Evaluate whether to commit to proceed with django-tree-queries for Location and LocationType models or revert to django-mptt patterns instead (see comments on Prototype Locations implementation #1891 and Django MPTT is no longer maintained - Migrate Existing Models to django-tree-queries #510)
• Implement a pattern for filtering Locations by base_site (which is a derived attribute, not a database field) so that for example when selecting a related Site while editing an object, the Location selection menu can filter to only display Locations that exist within that Site. (tracked as Need a UI pattern for filtering tree models by parent #2518)
• Polish up the documentation around LocationType and Location
  • If we're committing to merging Region and Site into Locations in 2.0, let's state that more firmly in the docs (Epic: Collapse Region and Site models into Location #2517)
  • Possibly update the Regions user guide to include creation of LocationTypes and Locations
  • Update docs relating to tenancy and Locations (explicitly state that a Location may have a Tenant, etc.)
• Evaluate database indexes on LocationType and Location to see if we need to add any explicit db_index=True, etc.
• Evaluate UI/UX around Location usage, in particular how select dropdowns present the Location hierarchy or obscure it depending on permitted content-types per LocationType.

Longer-term action items:

• Revisit how tree models are presented in UI list views (particularly as regards filtering of the list), possibly use JSTree or a similar library instead of django-tables2 for these models. (tracked as Tree view UI component #2516)

[bryanculver]

Initial Locations implementation was done by #1891. Known remaining action items:

• Evaluate whether to commit to proceed with django-tree-queries for Location and LocationType models or revert to django-mptt patterns instead (see comments on Prototype Locations implementation #1891 and Django MPTT is no longer maintained - Migrate Existing Models to django-tree-queries #510)

• Implement a pattern for filtering Locations by base_site (which is a derived attribute, not a database field) so that for example when selecting a related Site while editing an object, the Location selection menu can filter to only display Locations that exist within that Site. (tracked as Need a UI pattern for filtering tree models by parent #2518)

• Polish up the documentation around LocationType and Location

  • If we're committing to merging Region and Site into Locations in 2.0, let's state that more firmly in the docs (Epic: Collapse Region and Site models into Location #2517)
  • Possibly update the Regions user guide to include creation of LocationTypes and Locations
  • Update docs relating to tenancy and Locations (explicitly state that a Location may have a Tenant, etc.)

• Evaluate database indexes on LocationType and Location to see if we need to add any explicit db_index=True, etc.

• Evaluate UI/UX around Location usage, in particular how select dropdowns present the Location hierarchy or obscure it depending on permitted content-types per LocationType.

Longer-term action items:

• Revisit how tree models are presented in UI list views (particularly as regards filtering of the list), possibly use JSTree or a similar library instead of django-tables2 for these models. (tracked as Revisit how tree data models are presented in "list" views #2516)

All remaining actions have now been resolved.

#2516 will come in as a UX improvement for the UI overhaul.