feat(providers): ship built-in Jira and MLflow provider profiles #2547

Problem Statement

Developers using Jira (via MCP or REST) and MLflow in agent workflows must pass credentials as raw --env variables because no built-in provider profiles exist for these services. The existing provider system can hide these credentials — developers just can't use --type jira or --type mlflow because the profiles don't exist.

Built-in profiles for GitHub (github.yaml), NVIDIA (nvidia.yaml), and others ship in providers/ and are compiled into the binary. Jira and MLflow are among the most common non-inference services in agent workflows but have no built-in profiles.

Key Design Challenge: Per-Deployment Hostnames

Built-in profiles like github.yaml hardcode host: api.github.com because GitHub's API hostname is the same for everyone. Most other services don't have this property:

• Jira Cloud — each org has a different subdomain: redhat.atlassian.net, nvidia.atlassian.net, etc. A wildcard *.atlassian.net would inject credentials into requests to ANY Jira instance — a credential leak if the agent reaches a different org's instance.
• MLflow on OpenShift — hostname is cluster-generated, e.g. mlflow-redhat-ods-applications.apps.rosa.ian-cluster.g532.p3.openshiftapps.com
• Jira Server / Data Center — hostname varies per organization
• Self-hosted MCP servers — hostname varies per deployment

Built-in profiles for these services must not hardcode hosts. The profile supplies credentials, auth_style, protocol, and access rules — the developer supplies the host specific to their deployment at provider instance creation time.

Proposed: --host override at provider create

# Jira Cloud — org-specific subdomain
openshell provider create --name my-jira --type jira \
  --credential JIRA_API_TOKEN=<token> \
  --host redhat.atlassian.net

# MLflow — cluster-specific route
openshell provider create --name my-mlflow --type mlflow \
  --credential MLFLOW_TRACKING_TOKEN=$(oc whoami -t) \
  --host mlflow-redhat-ods-applications.apps.rosa.my-cluster.example.com

The --host flag sets the endpoint host for credential injection and policy composition. The built-in profile defines everything else.

Proposed Profiles

providers/jira.yaml

id: jira
display_name: Jira
description: Atlassian Jira REST API access
category: other
credentials:
  - name: api_token
    description: Jira API token
    env_vars: [JIRA_API_TOKEN]
    required: true
    auth_style: bearer
    header_name: authorization
discovery:
  credentials: [api_token]
endpoints:
  - port: 443
    protocol: rest
    access: read-only
    enforcement: enforce
    request_body_credential_rewrite: true
    # host omitted — developer supplies via --host (e.g., redhat.atlassian.net)

providers/mlflow.yaml

id: mlflow
display_name: MLflow
description: MLflow tracking server
category: data
credentials:
  - name: tracking_token
    description: MLflow tracking token
    env_vars: [MLFLOW_TRACKING_TOKEN]
    required: true
    auth_style: bearer
    header_name: authorization
discovery:
  credentials: [tracking_token]
endpoints:
  - port: 443
    protocol: rest
    access: read-write
    enforcement: enforce
    # host omitted — developer supplies via --host (e.g., cluster-specific route)

Dependencies

• If feat(providers): add mcp category for provider profiles #2546 lands first, the Jira profile could use category: mcp when configured for MCP access. Otherwise category: other works.

Motivation

Demonstrated in opendatahub-io/agent-ops#7 — Jira and MLflow credentials passed as raw env vars because no profiles existed. The demo used:

• Jira: redhat.atlassian.net (org-specific subdomain — a wildcard *.atlassian.net profile would be a credential leak risk)
• MLflow: mlflow-redhat-ods-applications.apps.rosa.ian-cluster.g532.p3.openshiftapps.com (cluster-generated hostname)

Both require per-instance host configuration. Neither can be hardcoded in a built-in profile.

Agent Investigation

• Built-in profiles compiled via include_str! in crates/openshell-providers/src/profiles.rs:26-38
• github.yaml is the closest pattern for non-inference profiles — uses category: source_control, auth_style: bearer
• request_body_credential_rewrite available since v0.0.85 for in-body placeholder replacement
• Custom profiles work today via openshell provider profile import, but built-in profiles with --host require zero YAML authoring
• Verified on live cluster: MLflow route is mlflow-redhat-ods-applications.apps.rosa.ian-cluster.g532.p3.openshiftapps.com — confirms dynamic hostname problem
• Jira Cloud uses org-specific subdomains (redhat.atlassian.net) — same problem, wildcard would leak credentials

Checklist

• Searched for existing issues — no issue tracks Jira or MLflow profiles specifically
• Profile schema follows existing github.yaml pattern
• Dynamic hostname problem identified for both Jira and MLflow
• --host override proposed to avoid credential leak via wildcards