docs/api/api.rst

   1 .. This work is licensed under a
   2 .. Creative Commons Attribution 4.0 International License.
   3 .. http://creativecommons.org/licenses/by/4.0
   4
   5 .. _api-label:
   6
   7 Policy Life Cycle API
   8 #####################
   9
  10 .. contents::
  11     :depth: 2
  12
  13 Policy life cycle API comprises of policy design API and policy deployment API. This documentation focuses on policy
  14 design API. Policy design API is publicly exposed for clients to Create/Read/Update/Delete (CRUD) policy types, policy type
  15 implementation and policies which can be recognized and executable by appropriate policy engines incorporated in ONAP
  16 policy framework. Policy design API backend is running in an independent building block component of policy framework
  17 that provides REST service for aforementioned CRUD behaviors. Policy design API component interacts with a policy database
  18 for storing and fetching new policies or policy types as needed. Apart from CRUD, API is also exposed for clients to retrieve
  19 healthcheck status of this API REST service and statistics report including a variety of counters that reflect the history
  20 of API invocation.
  21
  22 Starting from Dublin release, we strictly follow `TOSCA Specification <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.pdf>`_
  23 to define policy type and policy. Policy type is equivalent to policy model mentioned by clients before Dublin release.
  24 Both policy type and policy are included in a TOSCA Service Template which is used as the entity passed into API POST call
  25 and the entity returned by API GET and DELETE calls. More details are presented in following sessions.
  26 We encourage clients to compose all kinds of policies and corresponding policy types in well-formed TOSCA Service Template.
  27 One Service Template can contain one or more policies and policy types. Each policy type can have multiple policies created
  28 atop. In other words, different policies can match the same or different policy types. Existence of a policy type is a prerequisite
  29 of creating such type of policies. In the payload body of each policy to create, policy type name and version should be indicated and
  30 the specified policy type should be valid and existing in policy database.
  31
  32 Starting from El Alto release, to ease policy creation, we preload several widely used policy types in policy database. Below is a table summarizing
  33 preloaded policy types.
  34
  35 .. csv-table::
  36    :header: "Policy Type Name", "Payload"
  37    :widths: 15,10
  38
  39    "Controlloop.Guard.Blacklist", `onap.policies.controlloop.guard.Blacklist.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.controlloop.guard.Blacklist.yaml>`_
  40    "Controlloop.Guard.FrequencyLimiter", `onap.policies.controlloop.guard.FrequencyLimiter.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.controlloop.guard.FrequencyLimiter.yaml>`_
  41    "Controlloop.Guard.MinMax", `onap.policies.controlloop.guard.MinMax.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.controlloop.guard.MinMax.yaml>`_
  42    "Controlloop.Guard.Coordination.FirstBlocksSecond", `onap.policies.controlloop.guard.coordination.FirstBlocksSecond.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.controlloop.guard.coordination.FirstBlocksSecond.yaml>`_
  43    "Controlloop.Operational", `onap.policies.controlloop.Operational.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.controlloop.Operational.yaml>`_
  44    "Monitoring.TCA", `onap.policies.monitoring.cdap.tca.hi.lo.app.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app.yaml>`_
  45    "Monitoring.Collectors", `onap.policies.monitoring.dcaegen2.collectors.datafile.datafile-app-server.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.monitoring.dcaegen2.collectors.datafile.datafile-app-server.yaml>`_
  46    "Optimization", `onap.policies.Optimization.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.Optimization.yaml>`_
  47    "Optimization.AffinityPolicy", `onap.policies.optimization.AffinityPolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.AffinityPolicy.yaml>`_
  48    "Optimization.DistancePolicy", `onap.policies.optimization.DistancePolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.DistancePolicy.yaml>`_
  49    "Optimization.HpaPolicy", `onap.policies.optimization.HpaPolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.HpaPolicy.yaml>`_
  50    "Optimization.OptimizationPolicy", `onap.policies.optimization.OptimizationPolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.OptimizationPolicy.yaml>`_
  51    "Optimization.PciPolicy", `onap.policies.optimization.PciPolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.PciPolicy.yaml>`_
  52    "Optimization.QueryPolicy", `onap.policies.optimization.QueryPolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.QueryPolicy.yaml>`_
  53    "Optimization.SubscriberPolicy", `onap.policies.optimization.SubscriberPolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.SubscriberPolicy.yaml>`_
  54    "Optimization.Vim_fit", `onap.policies.optimization.Vim_fit.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.Vim_fit.yaml>`_
  55    "Optimization.VnfPolicy", `onap.policies.optimization.VnfPolicy.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policytypes/onap.policies.optimization.VnfPolicy.yaml>`_
  56
  57 Also, in El Alto release, We provide backward compatibility support for controlloop operational and guard
  58 policies encoded in legacy format. Below is a table containing sample legacy guard/operational policies and
  59 well-formed TOSCA monitoring policies.
  60
  61 .. csv-table::
  62    :header: "Policy Name", "Payload"
  63    :widths: 15,10
  64
  65    "vCPE.Monitoring.Tosca", `vCPE.policy.monitoring.input.tosca.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vCPE.policy.monitoring.input.tosca.yaml>`_  `vCPE.policy.monitoring.input.tosca.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vCPE.policy.monitoring.input.tosca.json>`_
  66    "vCPE.Optimization.Tosca", `vCPE.policies.optimization.input.tosca.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vCPE.policies.optimization.input.tosca.yaml>`_
  67    "vCPE.Operational.Legacy", `vCPE.policy.operational.input.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vCPE.policy.operational.input.json>`_
  68    "vDNS.Guard.FrequencyLimiting.Legacy", `vDNS.policy.guard.frequency.input.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vDNS.policy.guard.frequency.input.json>`_
  69    "vDNS.Guard.MinMax.Legacy", `vDNS.policy.guard.minmax.input.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vDNS.policy.guard.minmax.input.json>`_
  70    "vDNS.Monitoring.Tosca", `vDNS.policy.monitoring.input.tosca.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vDNS.policy.monitoring.input.tosca.yaml>`_  `vDNS.policy.monitoring.input.tosca.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vDNS.policy.monitoring.input.tosca.json>`_
  71    "vDNS.Operational.Legacy", `vDNS.policy.operational.input.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vDNS.policy.operational.input.json>`_
  72    "vFirewall.Monitoring.Tosca", `vFirewall.policy.monitoring.input.tosca.yaml <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vFirewall.policy.monitoring.input.tosca.yaml>`_  `vFirewall.policy.monitoring.input.tosca.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vFirewall.policy.monitoring.input.tosca.json>`_
  73    "vFirewall.Operational.Legacy", `vFirewall.policy.operational.input.json <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vFirewall.policy.operational.input.json>`_
  74
  75
  76 Below is a global API table from where swagger JSON for different types of policy design API can be downloaded.
  77 Global API Table
  78 --------------------
  79 .. csv-table::
  80    :header: "API name", "Swagger JSON"
  81    :widths: 10,5
  82
  83    "Healthcheck API", ":download:`link <swagger/healthcheck-api.json>`"
  84    "Statistics API", ":download:`link <swagger/statistics-api.json>`"
  85    "Tosca Policy Type API", ":download:`link <swagger/policytype-api.json>`"
  86    "Tosca Policy API", ":download:`link <swagger/policy-api.json>`"
  87    "Legacy Guard Policy API", ":download:`link <swagger/guard-policy-api.json>`"
  88    "Legacy Operational Policy API", ":download:`link <swagger/operational-policy-api.json>`"
  89
  90 API Swagger
  91 --------------------
  92
  93 It is worth noting that we use basic authorization for API access with username and password set to *healthcheck* and *zb!XztG34* respectively.
  94 Also, the new APIs support both *http* and *https*.
  95
  96 For every API call, client is encouraged to insert an uuid-type requestID as parameter.
  97 It is helpful for tracking each http transaction and facilitates debugging.
  98 Mostly importantly, it complies with Logging requirements v1.2.
  99 If client does not provider the requestID in API call, one will be randomly generated
 100 and attached to response header *x-onap-requestid*.
 101
 102 In accordance with `ONAP API Common Versioning Strategy Guidelines <https://wiki.onap.org/display/DW/ONAP+API+Common+Versioning+Strategy+%28CVS%29+Guidelines>`_,
 103 in the response of each API call, several custom headers are added::
 104
 105     x-latestversion: 1.0.0
 106     x-minorversion: 0
 107     x-patchversion: 0
 108     x-onap-requestid: e1763e61-9eef-4911-b952-1be1edd9812b
 109     x-latestversion is used only to communicate an API's latest version.
 110
 111 x-minorversion is used to request or communicate a MINOR version back from the client to the server, and from the server back to the client.
 112
 113 x-patchversion is used only to communicate a PATCH version in a response for troubleshooting purposes only, and will not be provided by the client on request.
 114
 115 x-onap-requestid is used to track REST transactions for logging purpose, as described above.
 116
 117 .. swaggerv2doc:: swagger/healthcheck-api.json
 118
 119 .. swaggerv2doc:: swagger/statistics-api.json
 120
 121 .. swaggerv2doc:: swagger/policytype-api.json
 122
 123 .. swaggerv2doc:: swagger/policy-api.json
 124
 125 When making a POST policy API call, the client must not only provide well-formed JSON/YAML,
 126 but also must conform to the TOSCA specification. For example. the "type" field for a TOSCA
 127 policy should strictly match the policy type name it derives.
 128 Please check out the sample policies in above policy table.
 129
 130 Also, in the POST payload passed into each policy or policy type creation call (i.e. POST API invocation), the client needs to explicitly
 131 specify the version of the policy or policy type to create. That being said, the "version" field is mandatory in the TOSCA service template
 132 formatted policy or policy type payload. Likewise in the legacy guard and the operational policy payload, "policy-version" is mandatory too.
 133 If the version is missing, that POST call will return "406 - Not Acceptable" and the policy or policy type to create will not be stored in
 134 the database.
 135
 136 To avoid inconsistent versions between the database and policies deployed in the PDPs, policy API REST service employs some enforcement
 137 rules that validate the version specified in the POST payload when a new version is to create or an existing version to update.
 138 Policy API will not blindly override the version of the policy or policy type to create/update.
 139 Instead, we encourage the client to carefully select a version for the policy or policy type to change and meanwhile policy API will check the validity
 140 of the version and feed an informative warning back to the client if the specified version is not good.
 141 To be specific, the following rules are implemented to enforce the version:
 142
 143 1. If the version is not in the database, we simply insert it. For example: if policy version 1.0.0 is stored in the database and now
 144    a client wants to create the same policy with updated version 3.0.0, this POST call will succeed and return "200" to the client.
 145
 146 2. If the version is already in the database, "406 - Not Acceptable" will be returned along with the message saying "specified version x.x.x"
 147    is already existing and the latest version is y.y.y. It can force the client to create a newer version than the latest one.
 148    For example, if policy versions "1.0.0" and "2.0.0" are already in the database and a client wants to create version "1.0.0" again, the
 149    client will get "406" code returned along with the message "specified version 1.0.0 is already existing and the latest version is 2.0.0".
 150    Then the client can change the version to anything newer than "2.0.0", such as "3.0.0".
 151
 152 3. If multiple policies or policy types are included in the POST payload, policy API will also check if duplicate version exists in between
 153    any two policies or policy types provided in the payload. For example, a client provides a POST payload which includes two policies with the same
 154    name and version but different policy properties. This POST call will fail and return "406" error back to the calling application along with a
 155    message such as "duplicate policy {name}:{version} found in the payload".
 156
 157 4. The same version validation is applied to legacy types of policies and policy types too (i.e. legacy guard and operational) so that everything
 158    is consistent.
 159
 160 5. To avoid unnecessary id/version inconsistency between the ones specified in the entity fields and the ones returned in the metadata field,
 161    "policy-id" and "policy-version" in the metadata will only be set by policy API. Any incoming explicit specification in the POST payload will be
 162    ignored. For example, A POST payload has a policy with name "sample-policy-name1" and version "1.0.0" specified. In this policy, the metadata
 163    also includes "policy-id": "sample-policy-name2" and "policy-version": "2.0.0". The 200 return of this POST call will have this created policy with
 164    metadata including "policy-id": "sample-policy-name1" and "policy-version": "1.0.0".
 165
 166 .. swaggerv2doc:: swagger/guard-policy-api.json
 167
 168 It is worth noting that guard policy name should start with one of the three: *guard.frequency.*, *guard.minmax.*, or *guard.blacklist.*.
 169 Otherwise, it will complain that guard policy type cannot be found (does not exist). Apart from policy name, the policy version specified
 170 in API path should be an integer, e.g. 1, 2, 10, instead of "1.0.0", "2.0.1", etc.
 171 These naming restrictions will disappear after we evolve to use well-formed TOSCA Service Template for guard policies and
 172 legacy policy design API is then deprecated.
 173
 174 .. swaggerv2doc:: swagger/operational-policy-api.json
 175
 176 Likewise, the policy version specified in operational policy API path should be an integer too, e.g. 1, 2, 10, instead of
 177 "1.0.0", "2.0.1", etc. This restriction will disappear after we deprecate legacy policy design API in the near future release.
 178
 179 Regarding DELETE APIs for both TOSCA policies and legacy policies, we only expose API to delete one particular version of policy
 180 or policy type at a time for safety purpose. If client has the need to delete multiple or a group of policies or policy types,
 181 they will need to delete one by one.
 182
 183 Sample API Curl Commands
 184 -------------------------
 185
 186 From API client perspective, using *http* or *https* does not have much difference in curl command.
 187 Here we list some sample curl commands (using *http*) for POST, GET and DELETE monitoring and operational policies that are used in vFirewall use case.
 188 JSON payload for POST calls can be downloaded from policy table above.
 189
 190 Create vFirewall Monitoring Policy::
 191   curl --user 'healthcheck:zb!XztG34' -X POST "http://{ip}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies" -H "Accept: application/json" -H "Content-Type: application/json" -d @vFirewall.policy.monitoring.input.tosca.json
 192
 193 Get vFirewall Monitoring Policy::
 194   curl --user 'healthcheck:zb!XztG34' -X GET "http://{ip}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies/onap.vfirewall.tca/versions/1.0.0" -H "Accept: application/json" -H "Content-Type: application/json"
 195
 196 Delete vFirewall Monitoring Policy::
 197   curl --user 'healthcheck:zb!XztG34' -X DELETE "http://{ip}:{port}/policy/api/v1/policytypes/onap.policies.monitoring.cdap.tca.hi.lo.app/versions/1.0.0/policies/onap.vfirewall.tca/versions/1.0.0" -H "Accept: application/json" -H "Content-Type: application/json"
 198
 199 Create vFirewall Operational Policy::
 200   curl --user 'healthcheck:zb!XztG34' -X POST "http://{ip}:{port}/policy/api/v1/policytypes/onap.policies.controlloop.Operational/versions/1.0.0/policies" -H "Accept: application/json" -H "Content-Type: application/json" -d @vFirewall.policy.operational.input.json
 201
 202 Get vFirewall Operational Policy::
 203   curl --user 'healthcheck:zb!XztG34' -X GET "http://{ip}:{port}/policy/api/v1/policytypes/onap.policies.controlloop.Operational/versions/1.0.0/policies/operational.modifyconfig/versions/1" -H "Accept: application/json" -H "Content-Type: application/json"
 204
 205 Delete vFirewall Operational Policy::
 206   curl --user 'healthcheck:zb!XztG34' -X DELETE "http://{ip}:{port}/policy/api/v1/policytypes/onap.policies.controlloop.Operational/versions/1.0.0/policies/operational.modifyconfig/versions/1" -H "Accept: application/json" -H "Content-Type: application/json"