Endpoint.url and Record.url doesn’t match

[johanfleury]

Hi.

I’m trying to script something around the netbox_dns plugin API and I’m unable to query zone records (at /api/plugins/netbox_dns/{id}/record).

I’ve tried using DetailEndpoint, but the class is getting its base URL from parent_obj.endpoint.url which has the wrong value:

>>> z = nb.plugins.netbox_dns.zones.get(1)
>>> z.endpoint.url
'https://netbox.br0.fr/api/netbox-dns/zones'

Record.url seems correct tho:

>>> z.url
'https://netbox.br0.fr/api/plugins/netbox-dns/zones/1/'

Details

• netbox: 3.1.1
• pynetbox: 6.4.1
• plugins: only netbox-dns (0.7.0)

[johanfleury]

I was able to workaround this issue with this:

class ZoneRecordsEndpoint(RODetailEndpoint):
    def __init__(self, parent_obj):
        super().__init__(parent_obj, "records", Record)
        self.url = "{}/{}/".format(parent_obj.url, "records")
        self.request_kwargs["base"] = self.url

[markkuleinio]

Hi, in case someone is trying to reproduce the problem, what are your plugin, NetBox and Pynetbox versions?

[johanfleury]

I’ve added details in the description.

[zachmoody]

I feel like a more comprehensive look at plugin support might be needed. There's a handful of places we assume certain behavior from NetBox, and the folks developing it have been pretty good about staying consistent with that pattern. Not saying this particular plugin doesn't do the same, but I don't know if we can continue to rely on that with an increasing number of community-driven plugins though.

[johanfleury]

IMO, the way pynetbox currently works with plugins is ok. The issue here is a programmatic one, not a design one nor an issue in how the plugin is developed.

~Also, having a “detail” endpoint is something that’s also done in the core API, and that’s why core.endpoints.DetailEndpoint and models.ipam exist.~ (disregard this, I didn’t see who I was replying to)

[zachmoody]

I just had something else that came up in another recent PR (https://github.com/netbox-community/pynetbox/pull/430) in mind when I wrote that. For that one, it looks like the endpoint went with underscores in its name vs the netbox "standard" of dashes. I was curious what the endgame was with the DetailEndpoint, but your example in the other PR issue helped. I was concerned we were going to start fielding requests for plugin models. :smiley:

[uedvt359]

@zachmoody: what do you think about the approach I've lined out in #430? Is this something that could be accepted into pynetbox?

[zachmoody]

@uedvt359 Would #433 work for your use-case? I'm leaning its way because there's a little better separation between plugins and native netbox functions.

[uedvt359]

Would #433 work for your use-case?

sorry, I didn't notice your response. I guess #433 could work, although AFAICT this would require implementing a secrets-plugin in every script we have; and a lot of that code is already in pynetbox right now. On the other hand, #430 only tries to restore functionality already present in NB2.x.

[zachmoody]

I get it, but I don't think it's our place to restore functionality that the parent project has moved on from. Feels like being a plugin means we have even fewer guarantees around its operation. Is it possible another secrets plugin could come along and implement get-session-key differently, or not at all?

[johanfleury]

I think we deviated a bit from the original issue here.

This one (#425) is about Endpoint.url being wrong for plugins, preventing pynetbox from working with plugins that have “detail endpoints”. This should be fixed by PR #426.

@zachmoody I’d say PR #426 could be merged as it is. I think it is the most important here as it fixes an actual bug. Also, it is not related to the current discussion about secret plugins and plugin models.

Regarding this discussion, PRs #433 and #430 are related to #392 (I’d argue that #433 need its own issue to discuss whether or not we want to keep secrets management in core pynetbox). I’d suggest that we continue this discussion there (in #392).

[DanSheps]

I just had something else that came up in another recent PR (#430) in mind when I wrote that. For that one, it looks like the endpoint went with underscores in its name vs the netbox "standard" of dashes. I was curious what the endgame was with the DetailEndpoint, but your example in the other PR issue helped. I was concerned we were going to start fielding requests for plugin models. 😃

Just to comment on this.

I think that you may be better off finding a way to handle "dashes" vs "underscore". Not every endpoint will use dashes or underscores consistently. This would leave you with a multitude of different possible combinations. However, with the increase in popularity for plugins due to the recent 3.2 release, it might be wise to find a way to allow "remapping" of plugin endpoints (maybe just a "installed plugins" arg so as to avoid trying to re-map the dash to a underscore, or allow aliasing or something).

The unfortunate thing is, /api/plugins/netbox_plugin/do-something is a perfectly valid URL design. It is unfortunate that you cannot use "-" in properties, but I think blindly re-mapping "_" to "-" is the wrong way to handle it.

[jcollie]

@zachmoody I’d say PR #426 could be merged as it is. I think it is the most important here as it fixes an actual bug.

What objections are there to merging #426? Without it (or something similar) trying to use plugins from pynetbox is hamstrung. Querying objects and creating objects work, but deleting objects certainly don't work, and most likely updating doesn't as well.