Prepare for Netbox 2.7 #209
Conversation
cimnine
added
the
maintenance
|
Any change of getting this merged? |
|
I know that 2.7 of Netbox was released and that Netbox Docker doesn't work out of the box with it right now. We will try to get it out as soon as possible. But frist, we'll merge #212 to release 0.20.0 of this project. Then we'll begin merging other PRs in the What you can do in the meantime is to build your own Docker Image. Switch to the branch of this PR ( FROM netboxcommunity/netbox:v2.7
COPY configuration/configuration.py /etc/netbox/config/configuration.py |
cimnine
force-pushed
the
2.7-prep
branch
3 times, most recently
from
29495be to
d74e1a3
Compare
|
This afternoon I was working hard on getting out scripts and configurations ready for Netbox 2.7. That is, there are several breaking changes to the initializers themselves. But I believe that they will be more stable now, as they don't rely on iterating through special lists anymore. This should make our initializers more generic and therefore more robust when future changes occur upstream. Note: This PR should be rebased onto |
The custom field database model has changed in Netbox 2.7. Therefore the initializer code, that was used before, broke. As a user, you will need to update your custom_fields.yml file as follows: - type must be lowercase - the `selection` type was changed to `select` - the filter_logic must be lower case This is to achieve compatibility with the naming schema that Netbox uses internally. It allows us to become forward compatible in case Netbox ever introduces a new type for custom fields. See the diff of this commit for further information how this is meant.
The rack database model has changed in Netbox 2.7. Therefore the initializer code, that was used before, broke. As a user, you will need to update your racks.yml file as follows: - Rack types must match one of the 5 rack types given, e.g. '4-post-cabinet'. - Rack width must match one of the 2 rack widths given, i.e. '19' or '23'. See the diff of this commit for further information how this is meant.
The device database model has changed in Netbox 2.7. Therefore the initializer code, that was used before, broke. As a user, you will need to update your devices.yml file as follows: - Make sure the rack face is spelled lowercase. See the diff of this commit for further information how this is meant.
The VLAN database model has changed in Netbox 2.7. Therefore the initializer code, that was used before, broke. As a user, you will need to update your vlans.yml file as follows: - Make sure the status is spelled lowercase. See the diff of this commit for further information how this is meant.
The vm database model has changed in Netbox 2.7. Therefore the initializer code, that was used before, broke. As a user, you will need to update your virtual_machines.yml file as follows: - Make sure the status is spelled lowercase. See the diff of this commit for further information how this is meant.
The interface database model has changed in Netbox 2.7. Therefore the initializer code, that was used before, broke. As a user, you will need to update your dcim_interfaces.yml file as follows: - Make sure the type is a value out of the possible choices. See the diff of this commit for further information how this is meant.
The ip address database model has changed in Netbox 2.7. Therefore the initializer code, that was used before, broke. As a user, you will need to update your ip_addresses.yml file as follows: - Make sure the status is written in lower case. See the diff of this commit for further information how this is meant.
Related Issue: N/A
New Behavior
Netbox 2.7 will support different Redis instances for caching and webhook queuing.
Therefore a second Redis server is added for caching.
This second Redis server does not persist it's data.
Contrast to Current Behavior
Currently only one Redis server serves both purposes, caching and webhook queuing.
But the two purposes have different requirements for the Redis server.
E.g. we don't want the webhooks to be lost when "the power goes out". Yet for the caching Redis we don't care about persistence, as the cache can be (and probably has to be) re-populated anyways.
Then the caching Redis is local to one instance of Netbox, whereas the webhook queue Redis is shared by at least two clients, the Netbox web instance and the Netbox rqworker instance.
The updated configuration is made in a backward-compatible way, so that users upgrading from previous versions of Netbox Docker, that don't update the
docker-compose.ymlfile, should not have to adjust anything in their setup, although I would recommend anyone to do so.Discussion: Benefits and Drawbacks
The drawbacks with two Redis's is of course that it takes a little bit more compute resources and the architecture became a little bit more complex to understand.
But at least from this project's perspective, if a user is getting started, he/she will not have to care about that, because it will just work out of the box, as it did in the past.
Changes to the Wiki
None. It is technically not even a breaking change.