How to interact with Nautobot objects in jobs

[phoenixswiss]

Hi there

This may be a dump question, but I haven't found any information in the developer's guide.

For "external" interaction with Nautobot, the REST APIs are clearly the way to go.

What is the intended way to interact with Nautobot objects like devices, interfaces, VLAN objects in Nautobot jobs? Is it ok to CRUD objects the "Django way" with create/delete/get/filter/save or is this a very bad practice?

filter_q = Q(device=device, type=InterfaceTypeChoices.TYPE_VIRTUAL)
nautobot_ip_interfaces = Interface.objects.filter(filter_q)

[Kircheneer]

This is absolutely okay, but you can simplify your example further, too:

nautobot_ip_interfaces = Interface.objects.filter(device=device, type=InterfaceTypeChoices.TYPE_VIRTUAL)

You only need Q if you plan on more complex filtering operations such as or/and filtering between different filters - see here for more information.

[jdrew82]

Is there something missing from the Jobs documentation? There are example Jobs provided towards the bottom. As you can see in the examples, you're absolutely welcome to use the standard Django ORM methods such as create, delete, etc. It would actually be advised to use those methods as you will have the best performance when interacting with the backend database using them. The one thing to be aware of though is that it's advised to use the validated_save() function when saving objects instead of the typical Django save() method. This enables validation of the object at creation time to ensure it's being created correctly and isn't missing any field data.

[phoenixswiss]

Hi,

Wow, that was very quick. Thanks for your answers and suggestions :-)

I did consult the Jobs wiki page, but I didn't actually find an example that called a Nautobot object class. This made me suspicious.

I have already developed a few jobs that update Nautobot objects using the standard Django ORM methods and saving them with validated_save(). They all worked as expected so far. Today I created my first job that creates objects. (IP addresses and virtual interfaces in Nautobot based on information gathered from an external tool). I noticed that custom fields aren't created on the interfaces object when creating them with Django ORM methods:

    __getUniqueVlanObj(self=self, device=device, all_nautobot_vlans=all_nautobot_vlans,
    vlanid=int(device_phpipam_ip["vlaninfo"]["number"]))

    nautobot_ip_interface = Interface.objects.create(
        device=device,
        name=ip_interface_name,
        type=InterfaceTypeChoices.TYPE_VIRTUAL,
        status=status_active,
        label=ip_interface_name,
        mgmt_only=mgmt_only,
        enabled=True,
        untagged_vlan=untagged_vlan,
        mode = "access"
    )

or

    __getUniqueVlanObj(self=self, device=device, all_nautobot_vlans=all_nautobot_vlans, 
    vlanid=int(device_phpipam_ip["vlaninfo"]["number"]))

    nautobot_ip_interface = Interface(
        device=device,
        name=ip_interface_name,
        type=InterfaceTypeChoices.TYPE_VIRTUAL,
        status=status_active,
        label=ip_interface_name,
        mgmt_only=mgmt_only,
        enabled=True,
        untagged_vlan=untagged_vlan,
        mode = "access"
    )
    
    nautobot_ip_interface.validated_save()

I noticed this because I was missing the check for the existence of a certain custom field in my custom transposer. I had to run nautobot-server fix_custom_fields on the server to create these missing fields on the interfaces I've created with Django ORM methods.

Have I missed something or is this expected behaviour?

[jathanism]

The latter pattern is better because Interface.objects.create() doesn't call the model valuation (aka model clean()), where validated_save() does as it calls clean() and then save() for you.

When using UI forms or API calls, the validation is always performed. When you use the ORM it is not, unless you call validated_save() yourself on your new model instances.

[glennmatthews]

Missing custom fields seems like a bug to me. (I actually thought we had an open issue around this already, but I can't find it at present.) CustomFieldModel.clean() at least will check and tell you if there are any required custom fields that you haven't specified values for, but it doesn't look like it has any code for automatically setting default values of custom fields that have defined default values, which seems wrong to me. I'd say feel free to open an issue with steps to reproduce the behavior you're seeing.

[phoenixswiss]

thank you guys

@glennmatthews: I'll open an issue