netorca_pack_data_info - Query NetOrca Pack stage data¶

Part of the netautomate.netorca collection (version 2.0.0). Added in version 2.0.0.

Synopsis¶

Retrieve pack data records - the per-stage payloads of NetOrca Pack pipeline runs.
Each record holds one stage's output for one object - what the config processor rendered, the verify verdict, or the execution result an executor pushed back - together with the scope it ran for and the service item declaration version it saw.
The staged lookup (object_id + stage) returns the newest record for that object and stage - typically "give me the rendered config I should deploy". For the full run context (state, cost, all stages together) use netautomate.netorca.netorca_pack_pipeline_info instead.
The pack executor endpoints are not covered by the netorca-sdk resource layer yet, so this module speaks to external/{context}/pack/data directly.

Requirements¶

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

netorca-sdk >= 1.0.9, < 2.0.0

Parameters¶

Parameter	Comments
id `int`	Return only the pack data record with this ID. If the ID does not exist, an empty list is returned.
object_id `int`	Together with `stage`, return the newest record of that stage for this service item (or service). Returns an empty list when the object has no data for the stage yet.
object_type `str`	What `object_id` refers to. Choices: `service_item`, `service` Default: `service_item`
stage `str`	The pipeline stage whose newest data the staged lookup returns. Choices: `config`, `verify`, `execution`

Common parameters¶

Connection and query parameters shared by every module in the collection. See Authentication for the environment-variable pattern.

Parameter	Comments
context `str`	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`, `consumer` Default: `serviceowner`
limit `int`	Maximum number of results to return. Results are auto-paginated, so by default all matching records are returned regardless of the API's page size.
ordering `str`	Server-side field to order results by, for example `created` or `modified`. Prefix with `-` for descending order - `-modified` returns the most recently changed records first.
api_url `str` required	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_key `str` required	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_certs `bool`	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	This module is read-only and runs identically with and without check mode.
diff_mode	N/A	This module never changes anything, so there is nothing to diff.

Notes¶

All modules talk to the NetOrca REST API and are typically executed on the controller (hosts=localhost with gather_facts=false, or delegate_to=localhost).
Module parameters take precedence over their NETORCA_* environment variable fallbacks.
Info modules never change anything and always return changed=false.
When nothing matches - including a lookup by ID that does not exist - info modules return an empty list rather than failing.
Filter options that accept a list match records with any of the given values (an OR filter, the platform's in lookup).

Examples¶

- name: The rendered config an executor should deploy for item 389
  netautomate.netorca.netorca_pack_data_info:
    object_id: 389
    stage: config
  register: config_data

- name: What the verify stage concluded
  netautomate.netorca.netorca_pack_data_info:
    object_id: 389
    stage: verify
  register: verdict

- name: All pack data visible to my team
  netautomate.netorca.netorca_pack_data_info:
    limit: 50
  register: all_data

- name: One record by ID
  netautomate.netorca.netorca_pack_data_info:
    id: 6534
  register: record

Return values¶

count¶

Number of returned pack data records.

Returned: always
Type: int
Sample:

pack_data¶

List of matching pack data records as returned by the NetOrca API.

Returned: always
Type: list / elements=dict
Sample:

[
  {
    "action_type": "config",
    "data": {
      "targets": []
    },
    "id": 6534,
    "object_id": 389,
    "scope": {
      "data": {
        "id": 389,
        "name": "crm-api"
      },
      "scope": "service_item"
    },
    "si_declaration": {
      "id": 552,
      "service_item": 389,
      "version": 1
    }
  }
]

Authors¶

NetAutomate (@netautomate)