Remove slugs from all models

[jeremystretch]

Proposed Changes

Remove the slug field from all models which have one. Any filters which reference the slug field will be modified to reference the object's name instead.

Justification

Slugs were phased out of use in URLs under #6097 and no longer serve any real purpose. NetBox users who utilize this field to store data should switch to using a custom field.

[DanSheps]

I would have to double check, but I do believe we use slugs in a few filters as a way to query (?role=xxx vs ?role_id=###)

This might be impactful for API reasons and we might want to look at that more carefully.

[DanSheps]

Thinking about this more...

I would have to vote against this. The recommendation for switching to custom fields, I feel, is too burdensome on the user. Custom fields aren't a "hard" field with specific requirements:

1. Requires "maintenance" of the slug custom field (if someone deletes it accidentally that could be disasterous)
2. There is no uniqueness constraint on a individual custom field. Two devices could potentially have the cf_slug "test" (Might be able to work around this with custom validators but that does add a extra burden on someone and I haven't even checked to see if this is possible).
3. Requires an additional REST API or Python API query (/api/ipam/prefixes/?tenant=dunder-mifflin vs /api/tenancy/tenant/?q=Dunder%20Mifflin and /api/ipam/prefixes/?tenant_id=#)
4. More prone to errors with lookups (tenant=dunder-mifflin vs where you have to perform a lookup for # first by searching against Dunder Mifflin in the tenant API, then fetch the data you need) Incorrect punctuation or a typo could result in incorrect or no data returned. This could happen with a slug field, however slug fields have certain restrictions that make this less likely (no whitespace, alphanum and -_ etc)
5. Python API, you cannot access the custom field in the same way as a slug (site__slug)
6. This would require manual migration of all slugs to PK's by those who utilize them. Also requires upgrading whatever integrations are in use to query against the custom field instead of the slug.

If some of these are addressable, maybe we mark this as blocked until we can implement those workarounds?

[rodvand]

I know the ansible modules heavily uses slugs for its functionality. So removing them would require a rework on the modules.

[jeremystretch]

1. Requires "maintenance" of the slug custom field

Does it? Only if you have a specific need to store a slug for an object in the first place, which I would guess most users do not.

2. There is no uniqueness constraint on a individual custom field.

As slugs are no longer used in URLs, there's really no need for them to be unique (or to exist at all).

3. Requires an additional REST API or Python API query

This is true for slugs as well: You can't assume that a slug is known ahead of time. You might be able to guess it 99% of the time, but that's not good enough to avoid querying entirely.

4. More prone to errors with lookups

Same as above. The argument is predicated on knowing the slug ahead of time, which is not reasonable.

5. Python API, you cannot access the custom field in the same way as a slug (site__slug)

You would access it as site__custom_field_data__slug. I don't see a significant distinction.

6. This would require manual migration of all slugs to PK's by those who utilize them.

Sure, and I think that's a reasonable one-time request to ditch a significant amount of unnecessary overhead. On the flip side, users who don't need slugs will never again be forced to populate them when creating objects.

I know the ansible modules heavily uses slugs for its functionality. So removing them would require a rework on the modules.

It's worth pointing out that only 21 or around 80 models currently have a slug field. So, presumably, we can simply standardize on those what we do for the others. Ultimately this should reduce code and make the library easier to maintain in general.

[kkthxbye-code]

I'm voting for. Slugs are for URL's, and if they are not used for URL's anymore, remove them.

If you know what object you want without lookup, just use the id.

[DanSheps]

Slugs are for URL's, and if they are not used for URL's anymore, remove them.

Technically not correct, a slug is a URL friendly label:

Source

Slug is a newspaper term. A slug is a short label for something, containing only letters, numbers, underscores or hyphens. They’re generally used in URLs.

We use them in URLs but that isn't all they are.

If you know what object you want without lookup, just use the id.

ID's are not always fixed, generally slugs are.

[kkthxbye-code]

We use them in URLs but that isn't all they are.

I'm not going engage in an argument based on the etymology of a word. How we use slugs in netbox should be all that matters.

https://en.wikipedia.org/wiki/Clean_URL#Slug

ID's are not always fixed, generally slugs are.

How can you change a pk in netbox from the UI or API without creating a new object? Are there any instances where you could see a valid reason to change the pk of an object? Essentially pk's are more static than slugs, because slugs can be changed at will.

[jeremystretch]

There's a compromise approach as well: We can just make slugs optional fields for now. This will at least alleviate the burden of having to define slugs that are otherwise unused, without interfering with those that are. I'd still like to eventually remove slugs completely, but this can happen at a later point in the future.

[sol1-matt]

I am voting against. I think removing slugs from Netbox is a bad idea. The reasons for this are

• the slug field is created automatically
• the slug field is a predictable computer friendly reference to the object that isn't a number.
• the slug value is enforced to be unique in a way that name isn't, it doesn't allow duplicates at the source
• the slug field has historically been a human readable reference between many objects in Netbox and any systems that use Netbox as a source or truth likely have a technical debt to them

Slugs are incredibly useful in any sort of automation compared with name or id. The types of automation I've had experience with are monitoring (Icinga), Ansible and other custom glue scripts that exchange data between Netbox and other sources.

Because slugs are automatically generated it makes it less likely humans will do something to break linked systems they don't know or care about, automatic slug creation does the work for them. Not having the slug created automatically at data entry time means the user needs to perform work previously done automatically and in the case of using a custom field as a replacement the linked object no longer shares the same value.

Having a automatically generated computer friendly, default /[a-z]-_/, unique value as a reference in the source or truth makes using that data in other systems easy to do. Being able to reference a site by slug, eg example or site_example, is has benefits over id, 123 or site_123. Both Icinga and Ansible benefit from slugs, Icinga because monitoring object names that contain the slug over id are instantly recognisable to the humans who manage monitoring, Ansible for the same reason as group names that use the slugs are referenced in playbooks so - host: site_example is much more readable than - host: site_123

The name of an object isn't a adequate replacement for slug, names are case sensitive and can have a much wider range of characters. The slug creation in Netbox simplifies the name (automatically) but will alert the user to problems only if found. It is particularly good a picking up objects with the same name but different case. There are 2 benefits to this a) Netbox is less likely to have bad or confusing data like the same server entered twice or assigned the same name and b) external system can trust the uniqueness of Netbox data.

Currently slugs are used as a reference between objects and are useful over id's. If in external systems we want to reference a devices site the slug between the 2 can be used. Monitoring and automation systems tend to be configuration based, not code based and as such humans will want to read the configuration, import site_example is easier to understand than import site_123

External systems replicating slugs on the way in
There are individual problems with this but the main effect is Netbox data is less truthful. Some of the individual problems introduced because Netbox no longer has slugs is

External slug creation errors due to duplicates or other human error gets moved from data entry time to export time.

External systems that import Netbox objects independently, ie 1 object type only, will only have the id as a link as the name part only exists on one side so a slug can only be created on one side, not both unless they are imported already linked.

External systems that import only one object type at a time that load linked objects to recreate slugs dramatically increase load, 2500 devices = 3 api calls now vs 3 api call + 2500 api calls per linked object or just load everything from all linked objects.

External systems that read data from Netbox and then later use that data to enhance data in Netbox will need to store Netbox specific references for the object that are seperate from the externally generated slug replacement because Netbox will no longer have any idea on what the object is.

[sol1-matt]

There's a compromise approach as well: We can just make slugs optional fields for now. This will at least alleviate the burden of having to define slugs that are otherwise unused, without interfering with those that are. I'd still like to eventually remove slugs completely, but this can happen at a later point in the future.

Optional as in a setting that is REQUIRE_SLUGS = TRUE or optional as in doesn't need to be filled out?

If it doesn't need to be filled out is it still filled out automatically?

Edit: Could we get some more examples of the problems slugs create, perhaps there is a different solution rather than removing slugs all together.

[jeremystretch]

the slug field is created automatically

Only when creating objects via the UI. There is no automation when using the REST API.

the slug field is a predictable computer friendly reference to the object that isn't a number.

As would be a custom field that replaces it.

the slug value is enforced to be unique in a way that name isn't, it doesn't allow duplicates at the source

I can't think of any instances where this is true. Uniqueness is enforced for both name and slug consistently for each model. They are redundant.

the slug field has historically been a human readable reference between many objects in Netbox and any systems that use Netbox as a source or truth likely have a technical debt to them

There are no inter-object relationships in NetBox which depend on the slug field. It was only ever used in URLs (gone in v2.11) and filter sets.

[sol1-matt]

Only when creating objects via the UI. There is no automation when using the REST API.

This is true, but I trust developers more than I trust users and it is generally easier to find the developers and tell them to change the code than retrain users

As would be a custom field that replaces it.

the custom field only exists on one side of a object, a site slug custom field would only exist on the site, the device wouldn't have any idea of what the site slug custom field is from itself it needs the id for that and if you are loading the whole site but using the site stub on the device object there is a problem

{
    "id": 99,
    "url": "https://demo.netbox.dev/api/dcim/devices/99/",
    "display": "FW001",
    "name": "FW001",
    ....
    "site": {
        "id": 21,
        "url": "https://demo.netbox.dev/api/dcim/sites/21/",
        "display": "MDF",
        "name": "MDF",
        "slug": "ncsu-065"
    },
    ...

I can't think of any instances where this is true. Uniqueness is enforced for both name and slug consistently for each model. They are redundant.

Case is the big one for uniqueness, slug is good at telling the user when they have been dumb and entered a duplicate with different case aka FooBar and Foobar. Some external systems are case insensitive and slug is a lifesaver when it comes to using Netbox as a source of truth for them.

There are no inter-object relationships in NetBox which depend on the slug field. It was only ever used in URLs (gone in v2.11) and filter sets.

I agree with that, but I wasn't referencing Netbox but other systems that use Netbox as a source of truth that recreate objects in their own way. Netbox's model approach translates well so it get replicated :)

Thinking about this more the benefits slugs give external applications might be resolved by allowing rules to be set around name. That way the cost of slugs could be removed but the benefits (a trusted field users can't screw up) could be retained, win-win.