Skip to content

netorca_pack_trigger - Trigger or retrigger a NetOrca Pack pipeline run

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

Synopsis

  • Start an AI processor run for a service item (or service) in NetOrca Pack.
  • A trigger starts the processor named by stage; the pipeline then advances through the later stages on its own (config runs verify, which runs or awaits execution). A retrigger (retrigger=true) always restarts the pipeline at config and can carry a service owner comment into the prompt - the self-healing loop after a failed or rejected deployment.
  • The platform also triggers pipelines itself when a change instance is approved (and validators when one arrives); this module is for manual runs, scheduled re-renders and the retrigger-with-feedback loop.
  • This is a fire-and-forget action; the run continues server-side after the module returns. Poll the outcome with netautomate.netorca.netorca_pack_pipeline_info (see its until example).
  • The pack executor endpoints are not covered by the netorca-sdk resource layer yet, so this module speaks to external/{context}/pack/trigger 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
comment
str		 Service owner feedback folded into the prompts of the retriggered run - tell the AI what went wrong ("the VLAN in the rendered config does not exist, use vlan 210").
Only valid with retrigger=true.
object_id
int
required		 ID of the service item (or service) to run processors for.
object_type
str		 What object_id refers to.
Choices: service_item, service
Default: service_item
retrigger
bool		 Restart the object's pipeline from config instead of starting one stage.
Default: false
stage
str		 Which processor to start - a pipeline stage (config, verify, execution), the optimiser, or the change_instance_validator.
Required unless retrigger=true; a retrigger always restarts at config.
Choices: config, verify, execution, optimiser, change_instance_validator

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
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 Reports what would be triggered without any API call. The existence of the target object is not validated in check mode.
diff_mode N/A A trigger has no before/after state to diff.

Notes

  • Every run invokes the service's LLM - each trigger costs real money (the accumulated amount is the pipeline's cost field). Guard loops accordingly.
  • Success means the platform accepted the trigger, not that the run will succeed - poll the pipeline state for the outcome.
  • 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.

Examples

- name: Re-render the config of a service item
  netautomate.netorca.netorca_pack_trigger:
    object_id: 389
    stage: config

- name: Self-heal after a failed deployment, with feedback for the AI
  netautomate.netorca.netorca_pack_trigger:
    object_id: 389
    retrigger: true
    comment: "deployment failed: pool member 10.0.0.20:8080 unreachable, use the standby pool"

- name: Trigger, then wait for the run to finish
  netautomate.netorca.netorca_pack_trigger:
    object_id: 389
    stage: config
  register: fired

- name: Poll until done
  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

Return values

msg

The platform's acknowledgement.

  • Returned: always
  • Type: str
  • Sample:
"AI Processor has been triggered"

See also

Authors

  • NetAutomate (@netautomate)