Access & Scoring

There are three reachable scoring paths once a model has been trained and (optionally) deployed:

1. Trainer sidecar at http://localhost:8003/invocations — useful for smoke tests and the Generated Python score_model.py.
2. Model server NodePort at http://localhost:30092/invocations — created when the model is deployed via the Deployments tab.
3. Ecosystem-runtime at http://localhost:30091/invocations — the recommended production path; applies logging, audit, and the campaign / sub-campaign contract. The runtime calls the configured trainer or deployed-server URL for api: model entries and normalizes the response into the canonical mojoScore shape, so existing post-score plugins keep working unchanged.

All three accept the same payload shape because the trainer sidecar emits an InvocationsRequest consistent with ecosystem-runtime.

Configuring mojo.key for an MLRun model

The runtime supports three model backends through a single mojo.key comma list (1-based mojo request indices preserved across types):

Add an api: entry of the form:

api:<framework>:<base_url>:<model_id>

For example:

mojo.key=GLM_v1.zip,api:xgboost:http://ecosystem-mlrun-trainer:8003:spend_risk_xgboost_v1

In ecosystem-workbench2, do not hand-edit mojo.key — instead, pick MOJO files and MLRun models in the Static Model section of the Deployment Editor. The backend joins model_configuration.models_load (MOJO filenames) with model_configuration.api_models[] (MLRun rows) into the final mojo.key value on push.

The MOJO picker lists .zip files at the deployment step’s paths.models_path (with a fallback to settings.h2o_models), preserving order so the 1-based mojo request index stays stable. The API model picker queries GET /api/v1/deployments/api-model-options which joins mlrun_models with mlrun_k8s_deployments so deployed models surface their NodePort URL while not-yet-deployed runs fall back to the trainer sidecar URL.

Sample scoring call (Customer Spend Risk)

curl -s http://localhost:8003/invocations -H 'content-type: application/json' \
  -d '{
    "model_id": "spend_risk_xgboost_v1",
    "instances": [
      {
        "amount_sum": 24500,
        "amount_mean": 322,
        "amount_std": 215,
        "declined_count": 4,
        "is_high_risk_categories": ["gambling"]
      }
    ]
  }'

Response:

{
  "model_id": "spend_risk_xgboost_v1",
  "framework": "xgboost",
  "predictions": [{ "label": 1, "probability": 0.87 }]
}

Sample scoring call (Customer Personality)

curl -s http://localhost:8003/invocations -H 'content-type: application/json' \
  -d '{
    "model_id": "customer_personality_lightgbm_v1",
    "instances": [
      {
        "age_band": "35_44",
        "gender": "F",
        "income_band": "high",
        "region": "metro",
        "life_stage": "family",
        "marital_status": "married",
        "dependents": 2,
        "tenure_months": 84
      }
    ]
  }'

Response (multiclass):

{
  "model_id": "customer_personality_lightgbm_v1",
  "framework": "lightgbm",
  "predictions": [{
      "label": "Industrious",
      "probabilities": {
          "Industrious": 0.51,
          "Intentional": 0.31,
          "Experiential": 0.12,
          "Enthusiastic": 0.06
      }
  }]
}

Scoring through ecosystem-runtime

Use the runtime when you want logging + audit. Map the project to a campaign / sub-campaign pair when configuring runtime deployment, then:

curl -s http://localhost:30091/invocate -H 'content-type: application/json' \
  -d '{
    "campaign": "customer_personality",
    "sub-campaign": "lightgbm",
    "channel": "web",
    "responses": 1,
    "in_params": {
      "input": ["age_band", "gender", "income_band", "region", "life_stage"],
      "value": ["35_44", "F", "high", "metro", "family"]
    }
  }'

The runtime writes a presented row to ecosystemruntime and an accepted row to ecosystemruntime_response (see Logging & Reporting).

Listing models for a project

curl -s http://localhost:8001/api/v1/mlrun-runtime/models?project_id=customer_personality

The response lists every successful run, the framework that produced it, the artifact URI, and the deployment id (when deployed).

Deleting an MLRun configuration

The Delete action on a configuration row (the trash icon in the Configurations list) opens a confirmation dialog and, on confirm, triggers a cascade delete that removes:

• The configuration row in ecosystem_meta.mlrun_configurations.
• The bound feature pipeline in ecosystem_meta.mlrun_feature_pipelines.
• The feature set in ecosystem_meta.mlrun_feature_sets.
• All training runs in ecosystem_meta.mlrun_training_runs.
• All K8s deployments in ecosystem_meta.mlrun_k8s_deployments for that project_id.

The toast that appears after the cascade prints the per-collection counts (e.g. “Removed 1 configuration, 1 pipeline(s), 1 feature set(s), 4 run(s).”), and a DELETE_MLRUN_CONFIGURATION activity row is written to ecosystem_meta.activities with the same counts and the user that requested the delete.