Plugin development question (dynamic fields)

[MalfuncEddie]

I would like to create a plugin that ansible can use to deploy software.
Different softwares have different settings/variables.

First (but a bit ugly) option:
Add a bunch of fields to the service model:
(Mockup)
Software -> Selection ["postgres", "Mariadb"]
Software_postgres_Version
Software_postgres_install_path
Software_postgres_some_postgres _setting

Software_mariadb_Version
Software_mariadb_install_path
Software__mariadb_some_mariadb _setting

Second option:
Create a bunch of models that are attached to a vm
model Software_postgres
version
path
foreign key to vm

model Software_mariadb
version
path
foreign key to vm

3rd option but don't know if this is possible:
create a generic software model that when you create it you can specify a type and that only shows the fields of that type

So basically I want a model that automagically changes fields on what is selected.
You select "add software"
First you select form a drop down "postgres" and then only the "postgres" settings are shown. This would have to be dynamic so that a user can define a "new software"

What would be the best course of action? I'm not quite good enough to write a plugin but am willing to learn, so I think the ugly "add a lot of custom fields to services" would be the easy way to go?

[mtinberg]

Where you put this kind of information is a matter of style and preference and I don't think there is one right answer. Config Contexts and Tags (among other fields, Platform, Site, etc.) can be used to attach bits of structured JSON data to Device records, which can work well for a number of things, JSON can even be configured directly on a Device. You could extend the Service model with custom fields or even create an entire Ansible variable-management GUI plugin, or more simply create a naming convention for Config Contexts that is directly looked up based on a small number of Custom Fields, but I think for the level of detail you are looking at you may want to manage this using YAML group_vars in the git repository where you manage the Ansible playbooks themselves, rather than creating and populating so many individual custom_fields. eg. if you want to use Config Context name: database_software filter: tag: "database_role" contents: "postgresql": "version": 12.3 "install_path": "/opt/postgres/" "mariadb": "version": 1.2.3 "install_path": "/opt/mariadb" Device: name: "db01" tags: - database_role then any device tagged with the "database_role" will have the data in config_contexts for db, with a custom_field saying which key hierarchy to go down (mariadb or postgresql) as a naming convention, then the editing of the variables is in config contexts in the Netbox GUI instead of the Ansible playbook repo. I'm not sure editing JSON in Netbox is any easier than editing YAML in a git project though, either one can provide a changelog and attribution of changes. another thing you can do config_context: database_role_postgresql_12 "database_type": "postgresql" "database_version": 12.2 "database_install_path": some place config_context: database_role_postgresql_13 "database_type": postgresql database_version: 13.1 database_install_path: other stuff config_context: database_role_mariadb_10 database_type: "mariadb" database_version: 10.7 database_install_path: another place with a matching set of tags, then the Ansible playbook could include the tasks for the right platform based on which database_type was set. You may want to set weights to ensure that newer versions override older ones if multiple tags are applied to the same host The big question though is whether maintaining this data in config contexts in the netbox gui is better for you than maintaining it in the playbook repo — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: MalfuncEddie ***@***.***> Sent: Wednesday, October 5, 2022 7:55 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] Plugin development question (dynamic fields) (Discussion #10569) I would like to create a plugin that ansible can use to deploy software. Different softwares have different settings/variables. First (but a bit ugly) option: Add a bunch of fields to the service model: (Mockup) Software -> Selection ["postgres", "Mariadb"] Software_postgres_Version Software_postgres_install_path Software_postgres_some_postgres _setting Software_mariadb_Version Software_mariadb_install_path Software__mariadb_some_mariadb _setting Second option: Create a bunch of models that are attached to a vm model Software_postgres version path foreign key to vm model Software_mariadb version path foreign key to vm 3rd option but don't know if this is possible: create a generic software model that when you create it you can specify a type and that only shows the fields of that type So basically I want a model that automagically changes fields on what is selected. You select "add software" First you select form a drop down "postgres" and then only the "postgres" settings are shown. This would have to be dynamic so that a user can define a "new software" What would be the best course of action? I'm not quite good enough to write a plugin but am willing to learn, so I think the ugly "add a lot of custom fields to services" would be the easy way to go? — Reply to this email directly, view it on GitHub<#10569>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM6EFXPWDUGAAB7P5ALWBV3FDANCNFSM6AAAAAAQ5RYZLQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[MalfuncEddie]

I agree with everything you just said. Especially the last part that variables are best stored in a repo.

If it wasn't for those damn managers that want to see it in the netbox gui so they view ( or even provision) software trough a gui.

Then again I can also query the api and python my way to an excel report.(I hate excel)

[mtinberg]

Gitlab exists so you can point people to a GUI to view/edit this data, if you are willing to run it. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: MalfuncEddie ***@***.***> Sent: Wednesday, October 5, 2022 10:47 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Plugin development question (dynamic fields) (Discussion #10569) I agree with everything you just said. Especially the last part that variables are best stored in a repo. If it wasn't for those damn managers that want to see it in the netbox gui so they view ( or even provision) software trough a gui. Then again I can also query the api and python my way to an excel report. — Reply to this email directly, view it on GitHub<#10569 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM4ET5KQLJ3CJMHUGL3WBWPKXANCNFSM6AAAAAAQ5RYZLQ>. You are receiving this because you commented.Message ID: ***@***.***>

[MalfuncEddie]

Gitlab exists so you can point people to a GUI to view/edit this data, if you are willing to run it.

You overestimate the technical knowledge of my management.

But the thinking it over on the drive home I think that all problems could be solved if I just create a custom json field (or use configuration context) and be able to create a custom table where if the column is a json field you can enter a query (JMESPath?) or a key form the json you want to show.

So feature request:
I would like the ability to enter a JMESPath when a custom field that is type "json"

it would be nice if you could enter a jsmpath query like

So that the table shows only certain fields of the json field

Is this something that is possible and should I try to put this in a feature request