Additional possibilities to control the configuration update process

[Oliver Kraitschy]

Hello everyone,

I'd like to propose and discuss additional possibilities to further control the configuration update process with OpenWISP.

Right now the configuration for a device can be defined (AFAIK):

- directly in the device config

- in templates which are enabled in the device config

- in templates which contain a tag included in the client config on the device

- in templates enabled by default

Nevertheless I'd like to have some more control over the update process:

- defining the order in which those templates are applied (for example to first upload a file to the device and then use it in the configuration)

- have some logic to define a set of devices the templates are applied to:

  - only apply a template to a specific device model (hardware)

  - only apply a template to devices who run a specific firmware version (field operating system)

  - only apply a template to devices which have a serial number within a certain range

  - only apply a template to devices which are within a certain ip range

  - only apply a template to devices which fulfill the opposite of a condition

I'd be happy to hear your thoughts and opinions on this.

Greetings,

Oliver

[Federico Capoano]

Hi Oliver,

On Fri, Oct 18, 2019 at 6:56 AM Oliver Kraitschy <okr...@arcor.de> wrote:

Hello everyone,

I'd like to propose and discuss additional possibilities to further control the configuration update process with OpenWISP.

Right now the configuration for a device can be defined (AFAIK):

- directly in the device config

- in templates which are enabled in the device config

- in templates which contain a tag included in the client config on the device

- in templates enabled by default

Nevertheless I'd like to have some more control over the update process:

- defining the order in which those templates are applied (for example to first upload a file to the device and then use it in the configuration)

By dragging templates up or down you can define the order in which they are merged to generate the final configuration.

Do you mean the order to apply it on the device?

 

- have some logic to define a set of devices the templates are applied to:

  - only apply a template to a specific device model (hardware)

  - only apply a template to devices who run a specific firmware version (field operating system)

  - only apply a template to devices which have a serial number within a certain range

  - only apply a template to devices which are within a certain ip range

  - only apply a template to devices which fulfill the opposite of a condition

I'd be happy to hear your thoughts and opinions on this.

 

At the moment I think the best thing is to implement this with django signals.

You could tag templates with something like "firmware2.1" or "ip-192.168.255.255", then connect a signal to the post_save of the Device model, you check the information you're interested in, for example, ip range, and then you look for templates tagged with that range and you assign them to the Device if necessary.

This kind of implementation does not need to change the core of OpenWISP and if we find out that more people need this and in the future we may design something that is already included.

What do you think?

Federico

[Oliver Kraitschy]

Am 18.10.19 um 18:30 schrieb Federico Capoano:

> Nevertheless I'd like to have some more control over the update process:
>
> - defining the order in which those templates are applied (for
> example to first upload a file to the device and then use it in the
> configuration)
>
> By dragging templates up or down you can define the order in which they
> are merged to generate the final configuration.
>
> Do you mean the order to apply it on the device?

Am I correct that this does basically define the priority of the templates?
Yes, I rather mean the order in which to apply the templates on the
device. For example, if one template contains a requirement for another
template, then the order would make sure that the first template is
applied before the second template gets rolled out.

> - have some logic to define a set of devices the templates are
> applied to:
>   - only apply a template to a specific device model (hardware)
>   - only apply a template to devices who run a specific firmware
> version (field operating system)
>   - only apply a template to devices which have a serial number
> within a certain range
>   - only apply a template to devices which are within a certain ip
> range
>   - only apply a template to devices which fulfill the opposite of
> a condition
>
> I'd be happy to hear your thoughts and opinions on this.
>
>
> At the moment I think the best thing is to implement this with django
> signals.
> You could tag templates with something like "firmware2.1" or
> "ip-192.168.255.255", then connect a signal to the post_save of the
> Device model, you check the information you're interested in, for
> example, ip range, and then you look for templates tagged with that
> range and you assign them to the Device if necessary.
>
> This kind of implementation does not need to change the core of OpenWISP
> and if we find out that more people need this and in the future we may
> design something that is already included.
>
> What do you think?

That sounds like a way to go. I'll have a look at that approach when I
have the time. Right now this topic doesn't have a high priority but I
wanted to discuss it early enough. Thank you :-)

Greetings,
Oliver

[Federico Capoano]

On Thu, Oct 24, 2019 at 4:42 PM Oliver Kraitschy <oli...@okraits.de> wrote:

Am 18.10.19 um 18:30 schrieb Federico Capoano:

>     Nevertheless I'd like to have some more control over the update process:
>
>     - defining the order in which those templates are applied (for
>     example to first upload a file to the device and then use it in the
>     configuration)
>
> By dragging templates up or down you can define the order in which they
> are merged to generate the final configuration.
>
> Do you mean the order to apply it on the device?

Am I correct that this does basically define the priority of the templates?
Yes, I rather mean the order in which to apply the templates on the
device. For example, if one template contains a requirement for another
template, then the order would make sure that the first template is
applied before the second template gets rolled out.

 

I'm not sure I understand the use case scenario well.

At the moment the configuration is downloaded, unpacked and installed on the device, only once that is done the services are reloaded, which means that the order in which files are written does not matter much, because services are reloaded only once every file is its place.

Why should it matter?

Federico