Netbox: Custom model validation exposed through plugins

Created on 21 Mar 2020  路  4Comments  路  Source: netbox-community/netbox

Environment

  • Python version: 2.7
  • NetBox version: 2.7.10

Proposed Functionality

Expose a plugin interface that allows for custom model validation to be performed when the model's clean() method is called. This interface will look similar to the plugin template content injection interface in which plugin developers specify the model they wish to act on. In this case, the class will implement only a single method validate():

class DeviceModelValidator(ModelValidator):
    model = 'dcim.device'

    def validate(self, obj):
        if obj.name == 'cat':
            raise ValidationError({
                'name': 'No cats allowed on the network!'
            })

As you can see, this method can either raise VailidationError or simply return None if the object passes validation. In the code path, these custom validators will be run at the end of the model's standard clean() method.

Use Case

As users adopt NetBox as a core component in automation solutions, data validity is key. NetBox reports can be used to highlight data consistency and integrity issues, but users must still fix these problems after the fact. By enforcing business logic rules when an object is created or updated, the chances of producing bad data are reduced.

The desire to implement custom validation has come up several times in the community before, but we have not really had a clean enough way to implement this until the plugins framework was born.

See: this comment, https://github.com/netbox-community/netbox/issues/3974, https://github.com/netbox-community/netbox/issues/3163, etc.

Database Changes

None

External Dependencies

The plugins framework introduced in 2.8.

plugins blocked feature

Most helpful comment

To further provide some use cases, here are a few I have noted with customers recently

Enforcing Business logic

  • Ensure that a hostname adheres to the internal naming standard.
  • Lookup to external system for new site creation, such as salesforce or similar.
  • Custom field verification such as "owner" on an IP address
  • Ensure every object is tied to a Tenant
  • Ensure consistency within subnetworks, e.g. only allow a /24 to be created within this /16

Many users "expect" the IPAM component to operate in a certain way. While it is clear that the base implementation cannot support that logic in order to support many more use cases, within the custom model validation you can add these capabilities.

  • Ensure that any network that has child networks is a "container"
  • Ensuring that no IP address within a container but not an active network is allowed. e.g. 10.10.0.0/16 container and only a 10.10.50.0/24 network, you should not be able to create an IP of 10.10.20.20 IP address
  • Ensure that IP addresses subnet mask matches up with the most specific network it is contained within

All 4 comments

I'm going to punt on this for the initial implementation as there's already _a lot_ going on. Let's put a pin in this until we figure out how we're going to handle feature requests for the plugins framework after the v2.8 release.

@jeremystretch can we pick this back up given the relatively light load of plugins related requests? I am happy to take this on.

Blocked by #4640

To further provide some use cases, here are a few I have noted with customers recently

Enforcing Business logic

  • Ensure that a hostname adheres to the internal naming standard.
  • Lookup to external system for new site creation, such as salesforce or similar.
  • Custom field verification such as "owner" on an IP address
  • Ensure every object is tied to a Tenant
  • Ensure consistency within subnetworks, e.g. only allow a /24 to be created within this /16

Many users "expect" the IPAM component to operate in a certain way. While it is clear that the base implementation cannot support that logic in order to support many more use cases, within the custom model validation you can add these capabilities.

  • Ensure that any network that has child networks is a "container"
  • Ensuring that no IP address within a container but not an active network is allowed. e.g. 10.10.0.0/16 container and only a 10.10.50.0/24 network, you should not be able to create an IP of 10.10.20.20 IP address
  • Ensure that IP addresses subnet mask matches up with the most specific network it is contained within
Was this page helpful?
0 / 5 - 0 ratings

Related issues

benjy44 picture benjy44  路  3Comments

bellwood picture bellwood  路  4Comments

hellerve picture hellerve  路  3Comments

shugotek picture shugotek  路  3Comments

Grokzen picture Grokzen  路  3Comments