Registrazione del Service

Definizione dei metadati base

Una volta aperto il form di registrazione Service cliccando su + Register Service, sarà possibile inserire i metadati base:

• Name*: nome del Service
• Version*: versione del Service
• URL*: docker://<dominio-tuo-registry-docker>:<porta>/<percorso-immagine>:<tag>

oltre a:

• Category
• Tags

entrambi utili a categorizzare i Service

^{Form registrazione service}

Documentare un Service

Sulla destra è invece disponibile un editor per l'inserimento della documentazione del Service in formato Markdown.

^{Registrazione service - aggiunta Markdown}

La documentazione inserita sarà consultabile dal Data Scientist utilizzatore del Service attraverso:

1. Pagina di dettaglio del Service

^{Dettaglio service - visualizzazione Markdown}

1. Workflow Designer

   Cliccando sul Service di interesse e poi su Documentation

   

   ^{Workflow Designer - Visualizza documentazione service}

   

   ^{Dettaglio documentazione}

Definizione delle Service Properties

Nella sezione Porte I/O abbiamo visto quali argomenti linea di comando definire a livello di programma nucleo. Adesso verrà mostrato come comunicare ad ALIDA la presenza di questi argomenti, in modo che la piattaforma possa valorizzarli e passarli correttamente.

In particolare dovrà esserci una Service Property per ogni argomento linea di comando base del programma nucleo. Non occorrerà quindi creare quelli per gli argomenti linea di comando specifici della Datasource

Le Service Property possono essere di tre tipi:

• Application
• Static
• Tuning
• Resource

Tipo Application

Per definire Porte I/O e Parametri di esecuzione configurabili, occorre registrare delle Service Property di tipo Application.

Andranno registrate quelle corrispondenti agli argomenti base visti nella sezione Porte I/O.

Porte Tipo Dataset, Model e Streaming

Per ciascuno degli argomenti base di questi tipi di porta qui riepilogati:

occorre creare una Service Property secondo le seguenti regole:

• Key: nome argomento (senza '--') (es. --input-dataset => input-dataset, il prefisso input/output sarà comunque obbligatorio)
• Description: a scelta
• Type: Application Property
• Mandatory: ticked
• Invisible: ticked
• Value Type: String
• Default Value: vuoto | ANY (nel caso di **key** --input-columns)
• Data Type: Input Data
• Streaming: unticked

Esempio per --input-dataset

^{Form inserimento service property}

Porta Tipo Generic I/O

Per una porta di tipo Generic occorre definire la Service Property come segue:

• Key: assets
• Description: a scelta
• Type: Application Property
• Mandatory: ticked
• Invisible: ticked
• Value Type: JSON
• Default Value:

  {
      "inputs":[
          {
              "name":"input-data",
              "path":"/inputs",
              "type":"dataset",
              "description":"my description"
          }
      ],
      "outputs":[
          {
              "name":"output-data",
              "path":"/outputs",
              "type":"dataset",
              "description":"my description"
          }
      ]
  }
  

• Data Type: Input Data
• Streaming: unticked

In questo modo all'interno del container del Service corrispondente, verranno montati due volumi vuoti raggiungibili dal programma nucleo all'interno del container sotto /inputs e /outputs

N.B. In fase di creazione del workflow, l'editor di inserimento delle variabili cambierà in base al tipo di properties, descrizione e valori default inseriti. Ecco un esempio relativo a due variabili. message (tipo JSON) e period (tipo stringa):

^{Dettaglio documentazione}

Porta Tipo REST API

La relativa Service Property è la seguente:

• Key: portsToExpose
• Description: a scelta
• Type: Application Property
• Mandatory: ticked
• Invisible: unticked
• Value Type: JSON
• Default Value:

  {
      "ports":[
          {
              "port":"<specificare-porta-esposta-dal-programma-nucleo>",
              "name":"default",
              "http_model":"rest",
              "url":null
          }
      ]
  }
  

• Data Type: Input Data
• Streaming: unticked

Questa properties se inserita, una volta salvato il Service e caricato in un Workflow, ci consentirà di esporlo in rete e di contattarlo tramite un URL che ci fornirà Alida al momento dell'esecuzione:

^{Esempio in UI di *Service* esposto}

Parametro di esecuzione configurabile

Per la definizione di parametri di esecuzione configurabili dall'utente attraverso l'UI del Workflow Designer:

• Key: nome argomento linea di comando (es. --my-param => my-param)
• Description: a scelta
• Type: Application Property
• Mandatory: ticked
• Invisible: unticked
• Value Type: tutti possibili
• Default Value: a scelta
• Data Type: Input Data
• Streaming: unticked

Tipo Static

Le Service Property di tipo Static permettono di passare al Service dei valori come variabili di ambiente al container e quindi al programma nucleo.

• Key: nome variabile d'ambiente
• Description: a scelta
• Type: Static
• Mandatory: ticked | unticked
• Invisible: unticked
• Value Type: tutti i possibili
• Default Value: a scelta
• Data Type: Input Data
• Streaming: unticked

Tipo resource

Le Service Property di tipo resource definiscono le quote di risorse richieste al runtime (Kubernetes) per il Service, e sono tutti parametri opzionali. Nel caso in cui il runtime non potesse soddisfare la richiesta, le risorse effettivamente allocate saranno inferiori.

Le metriche ammesse sono:

• CPU: espresso in millicores (es. 100m, 1000m = 1 CPU).
• Memory: espresso in Mi o Gi.
• GPU: unità intere (0, 1).
• AllowedRange: range ammesso.

^{Visualizzazione grafica del range nel workflow editor}

Sia per application ma anche per static, durante l'inserimento dei parametri richiesti dal Service, è possibile richiamare ed inserire le variabili d'ambiente presenti in piattaforma con la sintassi {{nomeVariabile}}.
Le variabili di ambiente disponibili saranno presenti all'interno della sezione "Global variables", accessibile tramite hamburger menu button in alto a sinistra: