Hi Edoardo, thank you for your feedback and I appreciate your concerns.
See below. On Tue, Nov 6, 2018 at 10:54 AM Edoardo Putti <[email protected]> wrote: > I already voiced my concern regarding this on the issue but I can tell you > more. > > You want to extend the schema of a backend and tha's a very interesting > feature. Right now it does > not work as expected as I found during GSOC 2017 [0]. The problem is that > you may redefine > some part of a schema which is already there and using `merge_config` as > in [1] does not update > the previous part and only add one. This may result in errors validating > the configuration against > the schema or worse invalid configuration passing the validation pass. > Yes you are right in the sense that we cannot use "merge_config" as it is in this case. We'll have to improve it, that shouldn't be hard, in the end it's just a recursive function and I'm willing to invest time in that if necessary. Maybe it would make sense to write a different function for merging schemas (merge_schema), because I designed merge_config to merge NetJSON configuration objects, where the merging of lists makes sense because in many cases you have an existing list in a template and you want to add to it. > Another problem you have to think of is that you are now modifying the > backend using `add_plugin` > . When will this happen? OpenWisp will load it? How it this going to > happen? Is this kind of configuration > part of the server or just the library? > It should happen during application startup, before django_netjsonconfig is loaded. Right now 2 main places come into my mind: the django settings file, or the ready() method of the django_netjsonconfig app config: https://github.com/openwisp/django-netjsonconfig/blob/master/django_netjsonconfig/apps.py We could facilitate this with a django setting which we could make available from ansible-openwisp2 with a YAML configuration, then we'd just to add how to do this in the user documentation and with that many users will find out how to do this cleanly without brutally hacking the openwisp core modules like many of them are doing now (there's really many people doing so, we only see the tip of the iceberg from github forks). > I'm not rejecting the `add_plugin` approach but I fear it can make the use > of the plugins extremely simple > and undebuggable. I would like the community to spin up more code for > supporting the configuration of > packages and such and I'm in favor of extensibility. I think my previous > work on netjsonconfig shows > this [2] and we can reuse the same approach for Converters leaving the > patch approach for experimentation. > The approach you are proposing here is very good for developers but you have to keep in mind most of our users are not python developers and they're looking for the fastest way to do what they want and if we don't provide it to them they will go as far as to brutally hacking the core code, they will go as far as to do this without even using a github repository. It's crazy, I know, but that's what I've observed networking people do for years (I've been working on this kind of networking applications professionally since 2012 with several companies and clients, I've literally seen all crazy shit and had to resort to all sort of zen meditation techniques to not go ballistic when I found out what they were doing). They are pressured by their company to do stuff quickly, they don't care about how clean it is, they just care it works. So we have to provide them an alternative which is clean enough but also fast to implement and works good for them. Regarding debugging with tools like ipdb, the django-debug-toolbar and sentry is not really a big concern in my humble opinion. It's good that you are pointing this out though, so we can invest some time in documenting how to try these kind of changes in a local development environment first, so if any bug is found we can explain how to drop a "import ipdb; ipdb.set_trace()" line and start inspecting the runtime logic to find out what's wrong. We should also set a boundary in our documentation explaining when using this "plugin" approach would be good and when would be better using an entirely custom backend is better. I would say that plugin approach is good when you want to use one of the default backends as is but you need to add support for a specific package while a custom backend should be used whenever more important logic or flows are changed or when testing experimental features or other firmwares/OSes altogether. What do you think? Federico -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
