Il prossimo task in attesa di volontari è... un installatore di connettori

Sisi sto lavorando proprio a questo.
Sono arrivato ad un punto che riesco a creare tramite UI dei connettori ( scaricandoli dal github page e creando azioni nuove tramite API ), mi funzionano tutti i connettori tranne quelli in Java.

Mi da questo errore qua quando invoco il connettore Java:
An error has occurred (see logs for details): java.lang.ClassNotFoundException: Main

{
    "namespace": "guest/util",
    "name": "postgresql.java-8.zip",
    "version": "0.0.2",
    "exec": {
        "kind": "java:8",
        "main": "Main",
        "binary": true
    },
    "annotations": [
        {
            "key": "provide-api-key",
            "value": false
        },
        {
            "key": "exec",
            "value": "java:8"
        }
    ],
    "limits": {
        "timeout": 60000,
        "memory": 256,
        "logs": 10,
        "concurrency": 1
    },
    "publish": false
}

Non essendo un mago del Java, potrei aver sbagliato l entrypoint sulla dichiarazione del main, ma sembra io non riesca a trovare un modo per farlo funzionare.

Il resto dei connettori funzionano correttamente, ora li salvo e li mostro sul menu.

Un altra domanda, alcuni correttori hanno bisogno di alcuni parametri in input:

  • GraphQL URL ad esempio per il graphql.python-3.zip

Questi parametri dovremmo chiederli all utente quando importano o mettiamo un campo args generico?

Ciao @Sf3ris

il connettore Java viene installato tramite un immagine docker specifica di openwhisk che permette di caricare tutte le dipendenze dallo zip.

Questo un esempio del comando:
wsk action update iosdk/import build/distributions/postgresql.java-8.zip.zip --main Main --docker openwhisk/actionloop-java-v8:nightly

Allora … chiariamo.

I connettori sono “funzioni” sviluppati in diversi linguaggi, che puoi “unit testare”, ma siccome per costruzione utilizzano componenti esterni per usarli o metti dei mock oppure metti l’effettivo ambiente. Per questo come dicevo l’ ambiente di build (e test) per ogni connettore tende ad essere differente… Credo che i connettori java che usano i database richiedano per il test un docker container che contiene il database stesso.

Io sono per seguire questa strada sempre.

Però tu puoi anche voler testare l’azione direttamente deployato in openwhisk, e hai due strade: o usare openwhisk full oppure solo il runtime.

Nel primo caso devi anche lanciare openwhisk usando la versione standalone (che è quello che faccio nella CI di IO-SDK) e usare il comando wsk
Nel secondo caso puoi lanciare direttamente il runtime con docker run -p 8080:80808 openwhisk/action-<language>-<Version> e comunicare con il runtime con lo script invoke.py.

Questo è tutto chiaro.

Grazie @frossi per la spiegazione dei connettori Java.

Come potete vedere da questa action che crea gli action per i connettori:

Purtroppo l azione al momento è agnostica dei dettagli di build del connettore, quindi se usa docker o meno.

A questo punto oltre a creare l index e le varie build ci sarebbe da aggiungere al gh pages anche i dettagli di build di ogni connettore , eventuali immagini docker, main entrypoint e altro.

Oltre a questi dati di “build”, anche gli argomenti da passare al connettore differiscono l uno dall altro. Ad esempio:

  • GraphQL.python => url
  • PHP => dbuser, dbpass
  • excel.node => file xls
  • ts.googlespreadsheet => credentials,file_id,file_name

Anche questi parametri dovrebbe essere esposti per permettere alla UI di parametrizzare gli input dei custom imports, o ci sono altri metodi migliori?

Spero di essermi spiegato, in caso insultate pure :slight_smile:

Ho un quesito, soprattutto per @msciab.
Attualmente i connettori di io-gateway-connectors non sono invocabili via web.

Cosa comporterebbe trasformarli in web actions?

Ad esempio il connettore excel.node ha questo codice:

function main(args) {
    let body = { "form": config.form }
    if(args.file) {
        let rows = importer(args.file)
        let data = []
        for(row of rows) 
            data.push(translate(row))
        body = { data: data }
    }
    return { "body": body }
}

Da quello che ho visto invocandolo da web il file verrebbe passato sotto args.__ow_body.file quindi la funzione diventerebbe :

function main(args) {
    let body = { "form": config.form }

    if('file' in args === false) {
        args = JSON.parse(args.__ow_body)
    }
    
    if(args.file) {
        let rows = importer(args.file)
        let data = []
        for(row of rows) 
            data.push(translate(row))
        body = { data: data }
    }
    return { "body": body }
}

Viene creato qualche problema di sicurezza adottando questa soluzione? o magari c’è qualche via piu pulita e adatta?

Il motivo principale è che senza il flag web l azione ha bisogno della chiave di autenticazione, della quale il frontend attualmente è agnostico.

Spero di essere stato chiaro.

non ho capito… i connettori SONO web actions… se il tuo problema è quello di gestire il file upload esponendo i dettagli ‘raw’ ‘ della form questo problema è già risolto: l’importatore prima passa l’input a una azione di utilitâ upload che trasforma un file in formato base 64 e poi lo ri posta come jspn. Questo per non complicare la vita a chi deve scrivere un connettore…

Mamma mia, il Venerdi sera non è un buon momento per essere concentrati.
Non mi leggeva i parametri in body perchè mi ero scordato di mettere l header json nella request.
Come non detto, cancelliamo l ultimo mio commento.

1 Mi Piace

Pensa te che io venerdì ho fatto un rilascio e mia moglie mi fa “ma la regola assoluta non era che venerdì sera e la vigilia di natale NON si fanno rilasci”?

2 Mi Piace

la regola d’oro :smiley:

Ho effettuato una PR abbastanza consistente per questa task.
Ovviamente da provare e testare, soprattutto se il risultato della funzionalità è quello aspettato.

Qui il link della PR:

Bellissimo! Lo provo ma mi ci vorrà qualche giorno (lo ammetto sono impelagato con faaswars.nimbella.com) , se qualcuno vuole fare anche lui il review e il test mi sareste di aiuto.

Rilasciamo senz’altro una versione 0.5.x (o addirittore 0.6) di IO-SDK con questa funzionalità. Questo potrebbe render opzionale l’editor che spaventa un sacco di gente.