netorca_deployed_item - Manage deployed items in NetOrca¶
Part of the netautomate.netorca collection (version 2.0.0). Added in version 2.0.0.
Synopsis¶
- Create, update or delete the deployed item of a service item - the record of what was actually deployed to fulfil it. Consumers see this record as the live, deployed state of their request, so keeping it accurate is part of operating a service well.
- The target deployed item is selected by
id, byservice_item_id, or bychange_instance_id(which resolves to the change's service item). If none exists yet, it is created; if one exists, its data is compared and only updated on difference, so the task is idempotent. - To attach a deployed item while completing a change instance in one call, use the netautomate.netorca.netorca_change_instance module's
deployed_itemoption instead. Use this module when the deployed record changes outside a change transition - for example after reconciling configuration drift or an out-of-band fix.
Requirements¶
The below requirements are needed on the host that executes this module.
- netorca-sdk >= 1.0.9, < 2.0.0
Parameters¶
| Parameter | Comments |
|---|---|
change_instance_idint |
Select the deployed item via a change instance; it is linked to that change on creation. |
datadict |
The deployed item payload - any JSON-serialisable description of what was deployed, for example the rendered tenant, record IDs or device-side object names. Compared deep against the existing data; the update is skipped when nothing differs. Required with state=present. |
idint |
ID of an existing deployed item. With state=present the deployed item must exist; use service_item_id or change_instance_id to create one. |
service_item_idint |
Select the deployed item belonging to this service item, creating it there if absent. |
statestr |
Whether the deployed item should exist. Choices: present, absentDefault: present |
Common parameters¶
Connection and query parameters shared by every module in the collection. See Authentication for the environment-variable pattern.
| Parameter | Comments |
|---|---|
contextstr |
Point of view for the request. The same query returns different data depending on which side of the service relationship your team is on.serviceowner operates on the services your team offers - the requests made against them, their service items and deployed items. This is the side that validates, approves, deploys and completes changes.consumer operates on what your team consumes - the service items your applications declared and the change instances tracking your own requests.If not set, the value of the NETORCA_CONTEXT environment variable is used.Choices: serviceowner, consumerDefault: serviceowner |
api_urlstrrequired |
Base URL of the NetOrca API, for example https://api.example.netorca.io.The URL is normalised to end in a single /v1, so passing it with or without the suffix both work.If not set, the value of the NETORCA_API_URL environment variable is used. |
api_keystrrequired |
API key of your NetOrca team. The NetOrca API supports API-key authentication only - there is no username/password mode. Treat the key like a password - supply it via the NETORCA_API_KEY environment variable (for example from a CI/CD secret) or from Ansible Vault, never as a literal in a playbook.If not set, the value of the NETORCA_API_KEY environment variable is used. |
validate_certsbool |
Whether to validate TLS certificates when talking to the API. Only disable this for lab instances with self-signed certificates. If not set, the value of the NETORCA_VALIDATE_CERTS environment variable is used.Default: true |
Attributes¶
| Attribute | Support | Description |
|---|---|---|
| check_mode | full | Create, update and delete are predicted from the fetched state without writing. |
| diff_mode | full | Returns before/after of the data payload on updates. |
Notes¶
- All modules talk to the NetOrca REST API and are typically executed on the controller (
hosts=localhostwithgather_facts=false, ordelegate_to=localhost). - Module parameters take precedence over their
NETORCA_*environment variable fallbacks.
Examples¶
- name: Record what was deployed for a service item
netautomate.netorca.netorca_deployed_item:
service_item_id: 1234
data:
fqdn: app01.example.com
record_id: 5541
- name: Record the deployment against the change instance being fulfilled
netautomate.netorca.netorca_deployed_item:
change_instance_id: 987
data:
policy_name: sec_pol_myapp
partition: Common
- name: Remove a deployed item
netautomate.netorca.netorca_deployed_item:
service_item_id: 1234
state: absent
Return values¶
deployed_item¶
The deployed item after the operation (or the projected result in check mode).
- Returned: when
state=present - Type:
dict - Sample:
msg¶
Human-readable summary of what happened.
- Returned: always
- Type:
str - Sample:
See also¶
- netautomate.netorca.netorca_change_instance - Attach a deployed item while completing a change instance in one call.
- netautomate.netorca.netorca_service_item_info - Find the service items whose deployed records you manage.
Authors¶
- NetAutomate (@netautomate)