How to use pynetbox inside a custom script?

[llamafilm]

How do you call pynetbox from within a custom script? I don't want to store an API token in the script because then the changelogs will always show that user's name, instead of the user who ran the script. I tried creating a temporary token in the script but that doesn't work, since the script runs atomically, that token is not actually available yet.

Example script, which fails: RequestError: The request failed with code 403 Forbidden: {'detail': 'Invalid token'}

from netaddr.ip import IPNetwork
import pynetbox
from extras.scripts import Script
from users.models.tokens import Token

class Debug(Script):
    class Meta:
        name = "Debug"

    def run(self, data, commit):
        netbox_token = Token(
            user=self.request.user,
            key=Token.generate_key(),
            description='script temp',
            allowed_ips=[IPNetwork('127.0.0.1/32')]
        )
        netbox_token.full_clean()
        netbox_token.save()

        self.nb = pynetbox.api(url='http://localhost:8001', token=netbox_token.key)
        self.log_info(self.nb.status())

        netbox_token.delete()

[llamafilm]

One possible answer is to instruct all users to create an API token with a specific name (e.g. local). I'm new to pynetbox so just wondering if there's a better, canonical way.

try:
    netbox_token = self.request.user.tokens.get(description='local').key
except Token.DoesNotExist:
    raise AbortScript("You must create an API token with name: `local` and allowed IPs: `127.0.0.1/32`.")

[candlerb]

I'm new to pynetbox so just wondering if there's a better, canonical way.

The better, canonical way is not to use pynetbox from within a custom script at all. You should use the Django ORM instead.

Yes, it's a different interface to learn, but your custom scripts will be much safer because they run inside a database transaction (i.e. all-or-nothing with rollback if something fails)

[llamafilm]

Well, in a way that makes me feel reassured, since all my custom scripts thus far have been using Django ORM methods. The all-or-nothing rollback feature is nice in some situations, but here it's actually causing a problem (see #17089).
This particular script touches every Netbox device, attaching images from an external API. With several thousand devices, this takes about 5 hours because that API is rather slow.

Since Netbox scripts are run as a single atomic transaction, the entire thing is reverted if the database connection is lost halfway through. In a cloud environment, this is very likely to happen occasionally due to network hiccups. Our database administrators strongly believe that long running transactions should be avoided as an anti-pattern, and that database clients should gracefully recover after a connection failure. To enforce this, we have "chaos daemons" (my made-up term) killing database connections at random intervals. Most parts of Netbox work fine with this philosophy, but it falls apart with custom scripts. So this is why I'm investigating pynetbox as an alternative.

[candlerb]

It sounds like you'd be better off dividing your overall task into separate jobs, running a separate custom script N times for N devices. Being separate script invocations, they will be in different database transactions. Then have a master custom script which submits the jobs. You could look at the runscript CLI to see how it does it; I would guess it uses the Job model.

Or you could just write Python code which runs outside of Netbox, in which case it can commit whenever it likes.