Add config context assignement to Tags in v2.11.x

[IDunkn0wn]

We internally use tags to generate interface configurations for the equipments, and since the implementation of the new model for tags, we have started updating our scripts to use the new tags objects as a dictionnay, meaning each entry (tag name) would have a value (tag description) in a json format.

A better way to take more advantage of this new data model, would be to be able to assign a config_context, therefore, enabling us to have custom interface profiles with a set of commands in json format, instead of relying on the config_context of that is applied to the devices.

[candlerb]

Please could you be more specific about what you're proposing?

In Netbox 2.11, you can already assign a config context to a tag with a weight. It is merged into the config context generated for devices or VMs with that tag. I've just tested it with v2.11.3 to be sure it works, and it does.

I don't understand how that relates to building a dictionary of {tag_name: tag_description}

[IDunkn0wn]

In Netbox 2.11, you can already assign a config context to a tag with a weight. It is merged into the config context generated for devices or VMs with that tag. I've just tested it with v2.11.3 to be sure it works, and it does.

I guess I could make a work around that by applying the tag to the config context instead of the other way around.

I don't understand how that relates to building a dictionary of {tag_name: tag_description}

It relates to it by having a json linked to a tag, so that when I apply for example "lacp_active" and "vm_tracer" tags on an interface, this would for example generate two different commands from the attached config context on the Tag.

So currently, I could work around this by having the command set in the description of the tag, but if lets say that I want to create a profile with a multiple set of commands which would extend to around 8 lines of cli commands, this would make it much easier for automation. By just adding them in a config context that is attached to the Tag object.

The workaround would be of course to have the config context itself tagged and then I would iterate through the config contexts, but it would make a lot of iterations on each loop.

So instead of just iterating through:
equipments > interfaces > tags
we would have an interation on:
equipements > interfaces > tags > config_contexts

[candlerb]

Sorry, again I don't really understand. You don't need to iterate over config_contexts; this is done for you automatically when you ask for the config context for a given device. All the related config_contexts are merged, in order of weight. You can see this in the "config context" tab for a particular device in the web UI, and you can ask for it via the API.

It is a deep merge, but identical keys are replaced. So suppose you have these config contexts:

# linked to tag "lacp_active" with weight 500
{"command": "xxxxx"}

# linked to tag "vm_tracer" with weight 1000
{"command": "yyyyy"}

and you have a device with both tags, then only {"command": "yyyyy"} will appear in the result. But if you change those config contexts to

# linked to tag "lacp_active" with weight 500
{
    "command": {
        "lacp": "xxxxx"
    }
}

# linked to tag "vm_tracer" with weight 1000
{
    "command": {
        "vm": "yyyyy"
    }
}

then the merged config context for that device has

{
    "command": {
        "lacp": "xxxxx",
        "vm": "yyyyy"
    }
}

This is regular JSON, so you can use lists instead of strings (for your multiple commands):

{
    "command": {
        "lacp": ["foo", "bar", "baz"]
    }
}

All this is out-of-box functionality, and so I still don't see why you say that a "workaround" is required. Can you provide a more concrete example?

[IDunkn0wn]

Yes that is indeed possible, but then the config_context and the merge would happen on a device level, correct?

here's the attributes of the config_context:

If I for example set the platform to for example CISCO, and the site to lets say EMEA, and then the tag to for example "example_tab", then the config context would be applied to all the equipements on the specified platform, site and tagged similarily to the context.

What I want though is more specific, since each interface has one or multiple different tags, the context should then be applied and merge to that interface, instead of the equipment itself. thus making the code less complicated and faster to execute. and of course won't be dependent on model changes done on netbox.

I hope this clears things up a bit better.

[candlerb]

The config context would be applied to all devices with the given tag "test_tag" (regardless of platform or site). You can create separate config contexts linked to sites or platforms, and they will also be applied and merged, at device or VM level.

What I want though is more specific, since each interface has one or multiple different tags

Now I get the point: you are tagging interfaces individually, and generating config snippets for individual interfaces. Config contexts aren't generated for interfaces - only for the whole device.

Perhaps what you want are custom fields on tags, but this was rejected in #5116.

I suggest that you keep an external table of config snippets for each interface tag and platform combination, either in your application which generates the configs, or in a plugin.