Location Schema Updates to address uniqueness issues

[ryanmerolle]

Background

I am working on enhancing this repo by:

• Adding more demo data/objects
• Tweaking the menu

Upon adding more demo data I found an issue with location modeling.

Issue/Proposal

I propose that Metro just becomes an attribute of Building instead of a relationship. The unfortunate but rather important reason is that even though there are only 3 city-states left in the world, Singapore is one with some important datacenter. There is no difference between Singapore the city or Singapore the country.

    - name: "APAC"
      shortname: "apac"
      children:
        kind: LocationCountry
        data:
          - name: "Singapore"
            shortname: "sg"
            children:
              kind: LocationMetro
              data:
                - name: "Singapore"
                  shortname: "sgc"
                  children:
                    kind: LocationBuilding
                    data:
                      - name: "SG1"
                        shortname: "sg1"
                      - name: "SG3"
                        shortname: "sg3"

           INFO     Created node: Singapore                                                                                                                      
['LocationMetroUpsert'] Node with id 188b94d7-6a8e-9803-2e41-c512f18eab84 exists, but it is a LocationCountry, not LocationMetro
✗ 📦 Failed: Loading bootstrap data (locations, platforms, roles, etc.)

This breaks the object loading given the hfid uniqueness issues between nodes/objects.

The below could address the issue in this case:

    uniqueness_constraints:
      - [parent, name__value]
    human_friendly_id:
      - parent__name__value
      - name__value

BUT countries can have towns/cities of the same name. Furthermore, in the US some states have multiple towns/cities of the same name. Maybe metro/city just does not make sense here and we should consolidate down to country being a parent of a building.

Additional Context

• I am open to thoughts and happy to create a pr to address this.
• This could be viewed as an infrahub bug for object loads since clearly the issue is failing to either create LocationMetro Singapore that is defined as such and associating to the parent of Singapore.

[petercrocker]

Really good observation about how to build a location hierarchy, I think my question is should this be changed in this example repo vs. a deployment-specific repo. If you have this edge case in your infra, there's multiple solutions. You mentioned one above. Another could be calling the LocationMetro node SingaporeMetro so it doesn't violate the uniqueness constraint and you can reference it by HFID and know if you're referring to LocationCountry or LocationMetro.

Part of the purpose of this repo is to show working examples of the Infrahub concepts, and keeping the example to the main concept without over-complicating it for certain edge cases makes it more understandable when people are trying to learn Infrahub schema development.

[ryanmerolle]

Very fair, comments. I was going to seed this with some reference data from all of Equinix color so people have a nice view of data in this demo. I guess I could just skip Singapore.