Management profiles - #1947
Conversation
This table will be used in combination with the netbox_profile table to define management profiles that can be attached to zero or more netboxes. The changescript also creates initial profiles from the existing netboxes, removes the old SNMP fields from Netbox and attaches the corresponding profiles to the existing netboxes.
We want/need proper JSONField support on this branch, which Django 1.8 does not support. Time to move right up there!
This will retain backwards-compatibility with SNMP-specific code that has not yet been ported to use management profiles.
Also rework Netbox bulk parser/importer to accept lists of management profiles rather than snmp config parameters.
Ensure all test fixtures use management profiles rather than setting or referencing the old SNMP attributes of Netboxes.
The bulk format now takes the names of profiles instead of SNMP config directly.
This is all taken care of in conftest!
The read_only attribute is, in fact, read only now. To remove SNMP config from the localhost netbox, delete its NetboxProfile entries.
Mimic these interim properties when fed an existing nav.models.manage.Netbox object to shadow, since they are still used by code.
This type will only be enabled when settings.DEBUG is True.
This includes moving the form implementations to a separate module.
The former is used by crispyforms to indicate what manually coded form fields from NAV/SeedDB indicate using the 'required' class.
This enabled the SeedDB interface to edit management profiles to dynamically switch out a fieldset of form fields related to specific protocol implementations. By selecting a protocol from the protocol dropdown, the correct fieldset for that protocol is made visible, while all the other protocol-specific fieldsets are hidden (and their form fields disabled).
This ensures that SeedDB is able to follow the relationships of ManagementProfiles to Netboxes when attempting to delete a profile (so the user can properly see that 42 Netboxes are using the profile they are about to delete).
sigmunau
left a comment
There was a problem hiding this comment.
Are there no existing tests for parsing and importing netboxes that should be updated here?
| self.helper.layout = get_single_layout('Filter connection profiles', 'protocol') | ||
|
|
||
|
|
||
| class ProtocolSpecificMixIn(object): |
| def __init__(self, *args, **kwargs): | ||
| super(ManagementProfileForm, self).__init__(*args, **kwargs) | ||
|
|
||
| def get_protocol_form_class(self): |
hmpf
left a comment
There was a problem hiding this comment.
What a monster, but kinda tricky to split it into several branches too.
It's not a nitpick, but it's also not an issue. I remember seeing the same thing before once, when reviewing one of your PRs: fb3df11 is in fact the direct parent of e65784b already, but it seems GitHub is displaying them in order of commit date in the PR view, not in their graph order (these commits have been heavily rebased back and forth). |
Obviously not (or they would have failed) :-( |
|
Alright, the docs have been sufficiently updated, finally merging this :-) |
This implements v1 of Management profiles in NAV, with attempted minimum invasiveness to existing SNMP-based code.
A management profile contains the necessary details needed to communicate with a device using some management protocol, save for an actual IP address to communicate with.
A Netbox/IP device will have a relation to 0 or more management profiles, which is a statement about how this device can be managed.
This PR:
DeprecationWarningwill be issued when these properties are accessed, to identify code that should probably change in the future.DEBUGprotocol, which is only enabled in DEBUG mode).ManagementProfilemodel requiresJSONField, which was only introduced in Django 1.9, to allow protocol implementations to store arbitrary profile information. This means Django 1.8 support must be dropped, and 1.11 is the next logical candidate, since all tests are passing on that version also on the master branch.This PR lacks:
Management profiles are a prerequisite to begin implementation of either #1177 or #1176.