nembery / vistoq2 Goto Github PK

For the baseline elements, the system will check if the xpath exists and if TRUE will bypass loading these xpath elements. Key example is shared tags.

If additional tags are added to the baseline in the same xpath, there is no way to force the load of new data since the system only checks if the xpath is True.

Request an admin config control to force load baseline elements for content updates with a branch of the xpath tree.

The templates support 2 types of variables: MSSP specific and customer specific.

The MSSP specific are used globally/regionally by the MSSP for their entire set of deployments. These are not exposed per device deployment in the web forms. Usage would be a conf file or hidden form fields when standing up the service as an MSSP.

The customer specific variables would be exposed in the form fields for each unique deployment. These would be autogenerated, pulled from OSS systems, or entered manually per customer.

Goal is to support both template types without a complete list of variables in each web form input.

Currently, a snippet set that extends another and contains variables gets all vars rendered as blank as they do not exist on the context.

Simple proposal is to load defaults from metadata into jinja context.

long term, we should be able to render all fields in the UI even for parent snippet sets

To simplify demo workflow, have the option to autoconfigure the G/S/B service and accept all defaults. This bypasses the second form submit, uses default MSSP values, and pushes the config to Panorama.

This also requires the system to generate the device name aka FW_NAME as device-group and template stack names.