What's the use for slugs in NetBox 2.11+?

[markkuleinio]

I'm successfully working with a NetBox-based automation project (2+ years now) where we have created the slugs as random strings. That's because in that system the site names can change any time, so we have wanted to keep the slugs meaningless to discourage changing them in GUI while changing the site name, as the slugs have been used in the URLs.

Now that the URLs no longer carry the slugs in NetBox 2.11+, the situation is different: it doesn't harm us if the slugs change.

So, what's the use for slugs ("URL-friendly unique shorthand" as help texts in GUI say) at the moment?

Actually, I see that if I want to filter objects by tags in the API, I have to use the tag slugs, I cannot use tag ID or a dict describing the tag (unless I did something wrong!). Is that the only use case for slugs, or are there others?

[jeremystretch]

Personally, I'd like to see slugs phased out completely (hence the change in #5873 to all ID-based URLs). We didn't want to just drop slugs completely, though, because some users rely on them to store necessary information (e.g. site codes).

[markkuleinio]

Ok, let's see later if the slugs will become optional or removed altogether, meanwhile I'll keep populating the site slugs with random values in the automation.

[candlerb]

In the long run, I'd like to see slugs become GUIDs that you could use to reference any object instead of its numeric ID. This would allow you to export/import/sync objects between different environments, where the database-allocated sequential ID may be different.

A CSV column with GUID would allow you both to import objects (if the GUID doesn't exist) and update objects (if the GUID matches an existing object).

Aside: at the moment, many objects now have id and slug and name and display (at least in the API), which seems redundant.

In the case of device_type it has id and slug and model and display and display_name!

  "device_type": {
    "id": 1,
    "url": "http://netbox/api/dcim/device-types/1/",
    "display": "DN2820FYKH",
    "manufacturer": {
      "id": 9,
      "url": "http://netbox/api/dcim/manufacturers/9/",
      "display": "Intel",
      "name": "Intel",
      "slug": "intel"
    },
    "model": "DN2820FYKH",
    "slug": "dn2820fykh",
    "display_name": "Intel DN2820FYKH"
  },
...
  "tags": [
    {
      "id": 7,
      "url": "http://netbox/api/extras/tags/7/",
      "display": "prom_node",
      "name": "prom_node",
      "slug": "prom_node",
      "color": "9e9e9e"
    }
  ],

Given that there's an ID and/or slug for API use, I don't see why both "name" and "display" are needed - who is ever going to see "name"? Although I can see why you might want "display:en", "display:es", "display:fr" etc.

[jeremystretch]

This would allow you to export/import/sync objects between different environments, where the database-allocated sequential ID may be different.

What would be the benefit of preserving a globally unique identifier, versus just assigning a locally unique PK as we do today? The tuple of (NetBox instance, model, PK) is already guaranteed to be unique.

A CSV column with GUID would allow you both to import objects (if the GUID doesn't exist) and update objects (if the GUID matches an existing object).

The same is true with the current sequential primary keys. This wouldn't be a blocker to supporting CSV-based updates (which is an entirely separate topic I won't get into here).

Given that there's an ID and/or slug for API use, I don't see why both "name" and "display" are needed - who is ever going to see "name"?

The display field was added in v2.11 to provide a consistent value for human-friendly labels for all objects. For models where name is optional (such as devices), it will populate an alternate value to ensure the user always sees something meaningful.

[candlerb]

What would be the benefit of preserving a globally unique identifier, versus just assigning a locally unique PK as we do today?

Use cases include merging two Netbox instances together, or exporting a subset of objects from one Netbox and importing them into another (non-empty) Netbox.

Right now, the approaches available are tricky:

1. Map all the source ids into ranges which are not in use in the target, and then SQL-insert them, adjusting ids and foreign key references to the mapped values as you insert; or
2. Import a root level class of objects (e.g. via API or script), note the ids auto-assigned in the new instance, maintain a mapping of old-id-to-new-id as you go, then insert child objects, update foreign keys via this mapping, etc. This is similar, but less flexible (e.g. you can't insert cycles of Device, primary_ip4/6 -> interface -> IPAddress in the same transaction).

You can't always reference another object by name or other non-id attribute. e.g. a device may have no name, or its name may only be unique within a particular scope.