Required Updates for "Up to" NetBox v3.4.2 Support

[tyler-8]

Just creating a task list here to consolidate the work required for NetBox v3.4.2 support. Any releases past that version will have to come after this work effort is done so we're not constantly chasing our tails.

• [x] https://github.com/lae/ansible-role-netbox/pull/154
• [x] https://github.com/lae/ansible-role-netbox/pull/155
• [ ] Netbox v3.2 has a NETBOX_DELETE_LEGACY_DATA environment variable to allow migrations to continue if data exists in the legacy ASN and Contact Name fields. https://github.com/netbox-community/netbox/commit/66464fd807b583a3605e8b65bb3f539daae33a31 Not sure how to best handle this one. If the environment variable is present (even with an empty string) it counts as "allow", it must be missing entirely to count as "deny".
• [ ] Set up of Custom Validators that reference classes. I'm thinking it should be handled the same way as reports and scripts?
• [ ] ~Postgres version requirements. Not sure if this should be handled by this role but I'm putting it here. NetBox v3.1 requires PostgreSQL 10 or later. NetBox v3.4 requires PostgreSQL 11 or later.~

If you have other requirements/ideas that are needed let me know and I'll add them to the list.

[tyler-8]

https://github.com/lae/ansible-role-netbox/issues/132 can be considered the "parent" issue

[lae]

Thanks for taking on this.

[lae]

NETBOX_DELETE_LEGACY_DATA

Historically, I've done a minor release bump (second number) for each minor version of NetBox. It's expected that admins upgrading read the release notes for those updates before updating, as well as the release notes for whatever NetBox version they're upgrading to. So...

In this case I would just suggest having a note in the release notes about executing ansible-playbook in a way that sets this environment variable and has it apply to the database migration task, since it sounds like it's just a one-time thing. If you write a statement for me and an appropriate playbook execution example I'll include that in the release notes.

Custom Validators

I guess I already came to the same conclusion as you in #157, but yes it seems similar to scripts and reports.

Postgres version requirements

I don't believe we've handled that in this role ever. The documentation just specifies prerequisite requirements. We currently use an admonition for specific version requirements but I guess we can make them into tables with the version progressions. And we'd of course mention these new requirements in the release notes.

---

Ideally I'd want to publish a new minor release for each minor NetBox release (one for 3.0.x, 3.1.x, 3.2.x...). Do you have that in mind? I guess I already merged a change for 3.2.x though :sweat_smile: Then again, piecemealing everything until we catch up might be best.

Also it looks like I didn't cut one for 3.0, but I don't remember if I just didn't get around to it or if there actually was something missing feature-wise....

[tyler-8]

NETBOX_DELETE_LEGACY_DATA

In this case I would just suggest having a note in the release notes about executing ansible-playbook in a way that sets this environment variable and has it apply to the database migration task, since it sounds like it's just a one-time thing. If you write a statement for me and an appropriate playbook execution example I'll include that in the release notes.

Sounds good!

Postgres version requirements

I don't believe we've handled that in this role ever. The documentation just specifies prerequisite requirements. We currently use an admonition for specific version requirements but I guess we can make them into tables with the version progressions. And we'd of course mention these new requirements in the release notes.

That sounds good. Otherwise we'd have to get into the weeds of checking database versions (that may live on remote servers).

Ideally I'd want to publish a new minor release for each minor NetBox release (one for 3.0.x, 3.1.x, 3.2.x...). Do you have that in mind? I guess I already merged a change for 3.2.x though 😅 Then again, piecemealing everything until we catch up might be best.

Also it looks like I didn't cut one for 3.0, but I don't remember if I just didn't get around to it or if there actually was something missing feature-wise....

To be honest I hadn't considered that approach here :P Thankfully there hasn't been too many "install/deployment" changes since the last official release of this role. Given how "far" behind the role has become from the latest version of NetBox, it just seemed easier to try and tackle it all together to try and catch up - using version checks for tasks where necessary.

[ironiq]

Just a note: in the today's state i was able to install v3.5.9 on CentOS7. This situation needs 2 things:

• enable centos-sclo-rh repository
• install rh-python38-python package.

After these you have to set the python3.8 binary path and everything works perfectly.

[ironiq]

Also just a sidenote: postgresql12 is also available from this repository, so not a big deal to install it.