netorca_pack_pipeline_info - Query NetOrca Pack pipeline runs¶

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

Synopsis¶

Retrieve pack pipelines - the recorded runs of the NetOrca Pack framework.
A pipeline is created every time a service item's AI processors run - automatically when a change instance is approved, or manually via netautomate.netorca.netorca_pack_trigger. It carries the output of each stage (config, verify, execution) as embedded pack data, the AI processor responses, the accumulated LLM cost, a version that increments per run, and the state - WAITING_FOR_RESPONSE while a stage is running or awaiting your executor, then OK or FAILED.
This is the polling half of the pack executor loop - fetch the latest pipeline of a service item, read its config output, apply it with your automation, push the result back with netautomate.netorca.netorca_pack_data, then mark the pipeline applied with netautomate.netorca.netorca_pack_pipeline.
The pack executor endpoints are not covered by the netorca-sdk resource layer yet, so this module speaks to external/{context}/pack/pipelines 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
application_id `list` / elements=`int`	Filter by ID of the consumer application the pipelines' service items belong to.
applied `bool`	Filter by the applied flag - whether an executor has marked the pipeline's output as deployed. `applied=false` with `state=OK` is the work queue of the executor loop.
consumer_team_id `list` / elements=`int`	Filter by ID of the consuming team.
declaration `dict`	Filter by exact match on fields of the pipeline's `config` stage data, for example `{"targets": [{"bigip_name": "BigIPWAF-D"}]}`.
declaration_contains `dict`	Filter by containment match on fields of the `config` stage data.
declaration_regex `dict`	Filter by regular expression match on fields of the `config` stage data.
end_date `str`	Only return pipelines created at or before this ISO 8601 timestamp.
id `int`	Return only the pipeline with this ID. When set, all other options are ignored. If the ID does not exist, an empty list is returned.
latest `bool`	Return only the newest pipeline of the object selected by `object_id` / `object_type` - the run your executor should act on. Default: `false`
object_id `int`	ID of the service item (or service) whose pipelines `latest` / `versions` look up.
object_type `str`	What `object_id` refers to. Choices: `service_item`, `service` Default: `service_item`
service_id `list` / elements=`int`	Filter by ID of the service.
service_item_id `list` / elements=`int`	Filter by ID of the service item the pipelines ran for.
start_date `str`	Only return pipelines created at or after this ISO 8601 timestamp.
state `list` / elements=`str`	Filter by pipeline state. Choices: `OK`, `FAILED`, `SCHEDULED`, `WAITING_FOR_RESPONSE`
version `list` / elements=`int`	Filter by run version.
versions `bool`	Return the run history of the object selected by `object_id` / `object_type` as a bare `{version, id}` list, newest first - a cheap way to detect a new run without fetching full pipelines. Default: `false`

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 executor work queue - successful runs not yet applied
  netautomate.netorca.netorca_pack_pipeline_info:
    state: [OK]
    applied: false
  register: queue

- name: The newest run for one service item
  netautomate.netorca.netorca_pack_pipeline_info:
    latest: true
    object_id: 389
  register: latest

- name: Wait until the triggered run finishes
  netautomate.netorca.netorca_pack_pipeline_info:
    latest: true
    object_id: 389
  register: run
  until: run.count == 1 and run.pack_pipelines[0].state in ['OK', 'FAILED']
  retries: 20
  delay: 15

- name: Run history of a service item (versions only)
  netautomate.netorca.netorca_pack_pipeline_info:
    versions: true
    object_id: 389
  register: history

Return values¶

count¶

Number of returned pipelines.

Returned: always
Type: int
Sample:

pack_pipelines¶

List of matching pipelines as returned by the NetOrca API. With versions=true the entries are bare {version, id} pairs. Stage outputs are embedded as pack data records under config, verify and execution; AI responses under ai_processor_response_*.

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

[
  {
    "applied": false,
    "config": {
      "action_type": "config",
      "data": {
        "targets": []
      },
      "id": 6534
    },
    "cost": 0.179445,
    "current_stage": "verify",
    "id": 2935,
    "state": "WAITING_FOR_RESPONSE",
    "version": 4
  }
]

Authors¶

NetAutomate (@netautomate)