Disabling Guard Checks

From Jorge:

Is it possible to have an option to disable them system wide on the PDP-D instead of a per policy basis, similar to the guard.disabled, or perhaps by removing the guard actor configuration?

the desire was to be able to disable guards on a per-policy basis, so disabling it system wide doesn't address the issue. However, one option, that would not require any code change, would be to simply segregate PDP-Ds into two different subgroups so that some are configured with guard.disabled=true, while the others are configured with guard.disabled=false.

Another option would be to introduce the guardDisabled flag in version 1.2.0 of the common.Drools policy type, so it doesn't impact existing policies and policy types. Then in PDP-D, we could introduce a second json schema to validate against that version, or we could just use the updated json schema in the associated review, as I believe it will work with policies of either type (although it would allow policies of type 1.1.0 to include a guardDisabled flag).

From Daniel:

Just a thought: why not add a 'guardDisabled' flag under the operational policy's operations payload? Each operation in the policy chain would specify whether to invoke guard or not by specifying 'guardDisabled' in the payload and thus satisfies the desire to have guard enabled/disabled on a per policy basis and does not require a model change. It would need a change in the Guard actor to check the payload's 'guardDisabled' flag over any configured environment value I think.

From Pam:

I can see wanting to disable guard calls per policy as well as per operation. Think of a health check, which may not be disruptive, thus no need to guard that call so you could save some cpu cycles. I'm a little worried that going around grouping PDPs differently to avoid guard calls may not be feasible in a production solution. I would think though that the guard should be enable/disable as specified by both policy and supported by the rules. I think we do leave this up to the developer/rule writer.

the downside of putting it into the payload is that the payload matters to the actors, so adding an extra property may or may not cause a problem with the actors.

in the future, I would imagine that a guard check would just be one more operation in the list of operations. Once that approach is taken, there would no longer be a need for flags at the policy or operation level. OTOH, there would still need to be a way for PDP-D to know whether or not guards were embedded within the list of operations - maybe use another policy type (which just happens to look like the existing policy type). We could accelerate the implementation of this approach to make it happen in Istanbul.

From Ram:

I agree with your suggestion of making guard as an operation in the operational policy. That makes it clear and more transparent than providing just a flag to enable/disable. Also users can provide few other parameters as well (ex - url of the xacml-pdp instance to use, etc.) Same holds good for AAI too. Regarding use cases, there are some where based on alarms from analytics, policy is triggering actions on CDS to create high priority tickets and assign them to network experts. And there are some use cases where the monitoring is not being done at device (VNF/PNF/CNF) level instead at individual interface in the device. And as of today AAI can't support such use cases. In general, it will be beneficial to allow users to build and support variety of use cases and not force them to follow certain predefined flow in the "usecases" controller that comes out of the box.

And I agree to Pam about not mixing it with multiple PDP group solution. As that makes production deployments difficult to manage (specially with the current OOM charts). Multi-tenancy (when it comes) will help in making the PDP instance tenant specific but still forces a tenant to have only one set of policies.

I think it would be fairly easy to add guard operations. However, AAI operations would be a bit trickier. For instance, only do the custom query if some particular data is needed from AAI, unless it's PNF data that is needed, then do the PNF query. And if you do the custom query, then you also need to do the tenant query first.

If we can come up with a good way to handle this complexity, then I would be willing to consider including AAI in the operations. You could potentially list the relevant AAI queries in their proper order, and use the "payload" to define conditions for which those queries would be executed. Or rather than putting the conditions in the "payload" of the AAI operations, you could define a "Condition" operation that is strictly used for execution control - those could then be used to control which AAI operations are performed, and in what order. Locks could also be made into operations.