aboutsummaryrefslogtreecommitdiffstats
path: root/models-examples/src/main/resources/policies/vFirewall.policy.monitoring.input.tosca.yaml
AgeCommit message (Collapse)AuthorFilesLines
2020-03-06TOSCA Compliant Guard PoliciesPamela Dragosh1-1/+1
Fixing the legacy guard policies and renaming them so we are able to differentiate them. Adding newer, cleaner TOSCA Guard Policies that match the operational guard policies. Removing legacy guard policies. Fixing JUnit so that they don't use indexes to test whether versions are changed correctly. Added back in new guard policies. Fixed the guard policy types to use camel case. Issue-ID: POLICY-2243 Change-Id: Ie611f26f73f41e64c0b467f524f470739158f437 Signed-off-by: Pamela Dragosh <pdragosh@research.att.com>
2020-02-07Add data type and policy type reference checkingliamfallon1-0/+1
Full validation including references to policy types and data types added. Unit tests fixed to cope with new stricter validation. Issue-ID: POLICY-1402 Change-Id: I59f37640a99494a53960a54d2fc82cc96861d43b Signed-off-by: liamfallon <liam.fallon@est.tech>
2019-05-07Set default and check existance of Policy Typeliamfallon1-1/+1
The TOSCA specification has a "bug" in that it does not have a field to specify the version of a policy type to use. We already had introduced the "type_version" field for this. This review introduces setting of the default version of a policy type to be be used by a policy as the latest version of the policy type in the database. As a side effect of this, we now have to check for existence of the policy type of a policy in the database. This means that creation/update of a policy with a non-existant policy type specified will now fail. Issue-ID: POLICY-1738 Change-Id: I27080cf6cd358948810dab6897c72dfe4d41fe91 Signed-off-by: liamfallon <liam.fallon@est.tech>
2019-03-19Move examples into separate moduleliamfallon1-0/+36
Issue-ID: POLICY-1195 Change-Id: Id2dc5b5b490134648ca267e27b795f3f4c03bc7b Signed-off-by: liamfallon <liam.fallon@est.tech>