oracle.oci.oci_dns_steering_policy_actions – Perform actions on a SteeringPolicy resource in Oracle Cloud Infrastructure

Note

This plugin is part of the oracle.oci collection (version 4.14.0).

You might already have this collection installed if you are using the ansible package. It is not included in ansible-core. To check whether it is installed, run ansible-galaxy collection list.

To install it, use: ansible-galaxy collection install oracle.oci.

To use it in a playbook, specify: oracle.oci.oci_dns_steering_policy_actions.

New in version 2.9.0: of oracle.oci

Synopsis

  • Perform actions on a SteeringPolicy resource in Oracle Cloud Infrastructure

  • For action=change_compartment, moves a steering policy into a different compartment.

Requirements

The below requirements are needed on the host that executes this module.

Parameters

Parameter Choices/Defaults Comments
action
string / required
    Choices:
  • change_compartment
The action to perform on the SteeringPolicy.
api_user
string
The OCID of the user, on whose behalf, OCI APIs are invoked. If not set, then the value of the OCI_USER_ID environment variable, if any, is used. This option is required if the user is not specified through a configuration file (See config_file_location). To get the user's OCID, please refer https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm.
api_user_fingerprint
string
Fingerprint for the key pair being used. If not set, then the value of the OCI_USER_FINGERPRINT environment variable, if any, is used. This option is required if the key fingerprint is not specified through a configuration file (See config_file_location). To get the key pair's fingerprint value please refer https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm.
api_user_key_file
string
Full path and filename of the private key (in PEM format). If not set, then the value of the OCI_USER_KEY_FILE variable, if any, is used. This option is required if the private key is not specified through a configuration file (See config_file_location). If the key is encrypted with a pass-phrase, the api_user_key_pass_phrase option must also be provided.
api_user_key_pass_phrase
string
Passphrase used by the key referenced in api_user_key_file, if it is encrypted. If not set, then the value of the OCI_USER_KEY_PASS_PHRASE variable, if any, is used. This option is required if the key passphrase is not specified through a configuration file (See config_file_location).
auth_purpose
string
    Choices:
  • service_principal
The auth purpose which can be used in conjunction with 'auth_type=instance_principal'. The default auth_purpose for instance_principal is None.
auth_type
string
    Choices:
  • api_key ←
  • instance_principal
  • instance_obo_user
  • resource_principal
The type of authentication to use for making API requests. By default auth_type="api_key" based authentication is performed and the API key (see api_user_key_file) in your config file will be used. If this 'auth_type' module option is not specified, the value of the OCI_ANSIBLE_AUTH_TYPE, if any, is used. Use auth_type="instance_principal" to use instance principal based authentication when running ansible playbooks within an OCI compute instance.
cert_bundle
string
The full path to a CA certificate bundle to be used for SSL verification. This will override the default CA certificate bundle. If not set, then the value of the OCI_ANSIBLE_CERT_BUNDLE variable, if any, is used.
compartment_id
string / required
The OCID of the compartment into which the steering policy should be moved.
config_file_location
string
Path to configuration file. If not set then the value of the OCI_CONFIG_FILE environment variable, if any, is used. Otherwise, defaults to ~/.oci/config.
config_profile_name
string
The profile to load from the config file referenced by config_file_location. If not set, then the value of the OCI_CONFIG_PROFILE environment variable, if any, is used. Otherwise, defaults to the "DEFAULT" profile in config_file_location.
region
string
The Oracle Cloud Infrastructure region to use for all OCI API requests. If not set, then the value of the OCI_REGION variable, if any, is used. This option is required if the region is not specified through a configuration file (See config_file_location). Please refer to https://docs.us-phoenix-1.oraclecloud.com/Content/General/Concepts/regions.htm for more information on OCI regions.
scope
string
    Choices:
  • GLOBAL
  • PRIVATE
Specifies to operate only on resources that have a matching DNS scope.
steering_policy_id
string / required
The OCID of the target steering policy.

aliases: id
tenancy
string
OCID of your tenancy. If not set, then the value of the OCI_TENANCY variable, if any, is used. This option is required if the tenancy OCID is not specified through a configuration file (See config_file_location). To get the tenancy OCID, please refer https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm

Examples

- name: Perform action change_compartment on steering_policy
  oci_dns_steering_policy_actions:
    # required
    steering_policy_id: "ocid1.steeringpolicy.oc1..xxxxxxEXAMPLExxxxxx"
    compartment_id: "ocid1.compartment.oc1..xxxxxxEXAMPLExxxxxx"
    action: change_compartment

    # optional
    scope: GLOBAL

Return Values

Common return values are documented here, the following are the fields unique to this module:

Key Returned Description
steering_policy
complex
on success
Details of the SteeringPolicy resource acted upon by the current operation

Sample:
{'_self': '_self_example', 'answers': [{'is_disabled': True, 'name': 'name_example', 'pool': 'pool_example', 'rdata': 'rdata_example', 'rtype': 'rtype_example'}], 'compartment_id': 'ocid1.compartment.oc1..xxxxxxEXAMPLExxxxxx', 'defined_tags': {'Operations': {'CostCenter': 'US'}}, 'display_name': 'display_name_example', 'freeform_tags': {'Department': 'Finance'}, 'health_check_monitor_id': 'ocid1.healthcheckmonitor.oc1..xxxxxxEXAMPLExxxxxx', 'id': 'ocid1.resource.oc1..xxxxxxEXAMPLExxxxxx', 'lifecycle_state': 'ACTIVE', 'rules': [{'cases': [{'answer_data': [{'answer_condition': 'answer_condition_example', 'should_keep': True, 'value': 56}], 'case_condition': 'case_condition_example', 'count': 56}], 'default_answer_data': [{'answer_condition': 'answer_condition_example', 'should_keep': True, 'value': 56}], 'default_count': 56, 'description': 'description_example', 'rule_type': 'FILTER'}], 'template': 'FAILOVER', 'time_created': '2013-10-20T19:20:30+01:00', 'ttl': 56}
 
_self
string
on success
The canonical absolute URL of the resource.

Sample:
_self_example
 
answers
complex
on success
The set of all answers that can potentially issue from the steering policy.

   
is_disabled
boolean
on success
Set this property to `true` to indicate that the answer is administratively disabled, such as when the corresponding server is down for maintenance. An answer's `isDisabled` property can be referenced in `answerCondition` properties in rules using `answer.isDisabled`.
"**Example:** \"rules\": [ { \"ruleType\": \"FILTER\", \"defaultAnswerData\": [ { \"answerCondition\": \"answer.isDisabled != true\", \"shouldKeep\": true } ] },"

Sample:
True
   
name
string
on success
A user-friendly name for the answer, unique within the steering policy. An answer's `name` property can be referenced in `answerCondition` properties of rules using `answer.name`.
**Example:**
" \"rules\": [ { \"ruleType\": \"FILTER\", \"defaultAnswerData\": [ { \"answerCondition\": \"answer.name == 'server 1'\", \"shouldKeep\": true } ] } ]"

Sample:
name_example
   
pool
string
on success
The freeform name of a group of one or more records in which this record is included, such as "LAX data center". An answer's `pool` property can be referenced in `answerCondition` properties of rules using `answer.pool`.
**Example:**
" \"rules\": [ { \"ruleType\": \"FILTER\", \"defaultAnswerData\": [ { \"answerCondition\": \"answer.pool == 'US East Servers'\", \"shouldKeep\": true } ] } ]"

Sample:
pool_example
   
rdata
string
on success
The record's data, as whitespace-delimited tokens in type-specific presentation format. All RDATA is normalized and the returned presentation of your RDATA may differ from its initial input. For more information about RDATA, see Supported DNS Resource Record Types.

Sample:
rdata_example
   
rtype
string
on success
The type of DNS record, such as A or CNAME. Only A, AAAA, and CNAME are supported. For more information, see Supported DNS Resource Record Types.

Sample:
rtype_example
 
compartment_id
string
on success
The OCID of the compartment containing the steering policy.

Sample:
ocid1.compartment.oc1..xxxxxxEXAMPLExxxxxx
 
defined_tags
dictionary
on success
Defined tags for this resource. Each key is predefined and scoped to a namespace. For more information, see Resource Tags.
**Example:** `{"Operations": {"CostCenter": "42"}}`

Sample:
{'Operations': {'CostCenter': 'US'}}
 
display_name
string
on success
A user-friendly name for the steering policy. Does not have to be unique and can be changed. Avoid entering confidential information.

Sample:
display_name_example
 
freeform_tags
dictionary
on success
Free-form tags for this resource. Each tag is a simple key-value pair with no predefined name, type, or namespace. For more information, see Resource Tags.
**Example:** `{"Department": "Finance"}`

Sample:
{'Department': 'Finance'}
 
health_check_monitor_id
string
on success
The OCID of the health check monitor providing health data about the answers of the steering policy. A steering policy answer with `rdata` matching a monitored endpoint will use the health data of that endpoint. A steering policy answer with `rdata` not matching any monitored endpoint will be assumed healthy.
**Note:** To use the Health Check monitoring feature in a steering policy, a monitor must be created using the Health Checks service first. For more information on how to create a monitor, please see Managing Health Checks.

Sample:
ocid1.healthcheckmonitor.oc1..xxxxxxEXAMPLExxxxxx
 
id
string
on success
The OCID of the resource.

Sample:
ocid1.resource.oc1..xxxxxxEXAMPLExxxxxx
 
lifecycle_state
string
on success
The current state of the resource.

Sample:
ACTIVE
 
rules
complex
on success
The series of rules that will be processed in sequence to reduce the pool of answers to a response for any given request.
The first rule receives a shuffled list of all answers, and every other rule receives the list of answers emitted by the one preceding it. The last rule populates the response.

   
cases
complex
on success
An array of `caseConditions`. A rule may optionally include a sequence of cases defining alternate configurations for how it should behave during processing for any given DNS query. When a rule has no sequence of `cases`, it is always evaluated with the same configuration during processing. When a rule has an empty sequence of `cases`, it is always ignored during processing. When a rule has a non-empty sequence of `cases`, its behavior during processing is configured by the first matching `case` in the sequence. When a rule has no matching cases the rule is ignored. A rule case with no `caseCondition` always matches. A rule case with a `caseCondition` matches only when that expression evaluates to true for the given query.

     
answer_data
complex
on success
An array of `SteeringPolicyFilterAnswerData` objects.

       
answer_condition
string
on success
An expression that is used to select a set of answers that match a condition. For example, answers with matching pool properties.

Sample:
answer_condition_example
       
should_keep
boolean
on success
Keeps the answer only if the value is `true`.

Sample:
True
       
value
integer
on success
The rank assigned to the set of answers that match the expression in `answerCondition`. Answers with the lowest values move to the beginning of the list without changing the relative order of those with the same value. Answers can be given a value between `0` and `255`.

Sample:
56
     
case_condition
string
on success
An expression that uses conditions at the time of a DNS query to indicate whether a case matches. Conditions may include the geographical location, IP subnet, or ASN the DNS query originated. **Example:** If you have an office that uses the subnet `192.0.2.0/24` you could use a `caseCondition` expression `query.client.address in ('192.0.2.0/24')` to define a case that matches queries from that office.

Sample:
case_condition_example
     
count
integer
on success
The number of answers allowed to remain after the limit rule has been processed, keeping only the first of the remaining answers in the list. Example: If the `count` property is set to `2` and four answers remain before the limit rule is processed, only the first two answers in the list will remain after the limit rule has been processed.

Sample:
56
   
default_answer_data
complex
on success
Defines a default set of answer conditions and values that are applied to an answer when `cases` is not defined for the rule, or a matching case does not have any matching `answerCondition`s in its `answerData`. `defaultAnswerData` is not applied if `cases` is defined and there are no matching cases. In this scenario, the next rule will be processed.

     
answer_condition
string
on success
An expression that is used to select a set of answers that match a condition. For example, answers with matching pool properties.

Sample:
answer_condition_example
     
should_keep
boolean
on success
Keeps the answer only if the value is `true`.

Sample:
True
     
value
integer
on success
The rank assigned to the set of answers that match the expression in `answerCondition`. Answers with the lowest values move to the beginning of the list without changing the relative order of those with the same value. Answers can be given a value between `0` and `255`.

Sample:
56
   
default_count
integer
on success
Defines a default count if `cases` is not defined for the rule or a matching case does not define `count`. `defaultCount` is **not** applied if `cases` is defined and there are no matching cases. In this scenario, the next rule will be processed. If no rules remain to be processed, the answer will be chosen from the remaining list of answers.

Sample:
56
   
description
string
on success
A user-defined description of the rule's purpose or behavior.

Sample:
description_example
   
rule_type
string
on success
The type of a rule determines its sorting/filtering behavior. * `FILTER` - Filters the list of answers based on their defined boolean data. Answers remain only if their `shouldKeep` value is `true`.
* `HEALTH` - Removes answers from the list if their `rdata` matches a target in the health check monitor referenced by the steering policy and the target is reported down.
* `WEIGHTED` - Uses a number between 0 and 255 to determine how often an answer will be served in relation to other answers. Anwers with a higher weight will be served more frequently.
* `PRIORITY` - Uses a defined rank value of answers to determine which answer to serve, moving those with the lowest values to the beginning of the list without changing the relative order of those with the same value. Answers can be given a value between `0` and `255`.
* `LIMIT` - Filters answers that are too far down the list. Parameter `defaultCount` specifies how many answers to keep. **Example:** If `defaultCount` has a value of `2` and there are five answers left, when the `LIMIT` rule is processed, only the first two answers will remain in the list.

Sample:
FILTER
 
template
string
on success
A set of predefined rules based on the desired purpose of the steering policy. Each template utilizes Traffic Management's rules in a different order to produce the desired results when answering DNS queries.
**Example:** The `FAILOVER` template determines answers by filtering the policy's answers using the `FILTER` rule first, then the following rules in succession: `HEALTH`, `PRIORITY`, and `LIMIT`. This gives the domain dynamic failover capability.
It is **strongly recommended** to use a template other than `CUSTOM` when creating a steering policy.
All templates require the rule order to begin with an unconditional `FILTER` rule that keeps answers contingent upon `answer.isDisabled != true`, except for `CUSTOM`. A defined `HEALTH` rule must follow the `FILTER` rule if the policy references a `healthCheckMonitorId`. The last rule of a template must must be a `LIMIT` rule. For more information about templates and code examples, see Traffic Management API Guide.
**Template Types**
* `FAILOVER` - Uses health check information on your endpoints to determine which DNS answers to serve. If an endpoint fails a health check, the answer for that endpoint will be removed from the list of available answers until the endpoint is detected as healthy.
* `LOAD_BALANCE` - Distributes web traffic to specified endpoints based on defined weights.
* `ROUTE_BY_GEO` - Answers DNS queries based on the query's geographic location. For a list of geographic locations to route by, see Traffic Management Geographic Locations.
* `ROUTE_BY_ASN` - Answers DNS queries based on the query's originating ASN.
* `ROUTE_BY_IP` - Answers DNS queries based on the query's IP address.
* `CUSTOM` - Allows a customized configuration of rules.

Sample:
FAILOVER
 
time_created
string
on success
The date and time the resource was created, expressed in RFC 3339 timestamp format.
**Example:** `2016-07-22T17:23:59:60Z`

Sample:
2013-10-20T19:20:30+01:00
 
ttl
integer
on success
The Time To Live (TTL) for responses from the steering policy, in seconds. If not specified during creation, a value of 30 seconds will be used.

Sample:
56


Authors

  • Oracle (@oracle)