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

Progetti IO-SDK
#1

A grande richiesta apro una discussione per ogni cosa aperta in cui ci si vuole cimentare.
Un task aperto è un modo di installare i connettori a partire dai binari.

Tradotto significa:

  1. una form che lista tutti i connettori disponibli (dovrebbero essere ottenute chiamato una api di GitHub che lista le release per il progetto pagopa/io-gateway-connectors)

  2. Selezinando un connettore si invoka una azione che deve creare una nuova azione a partire da quella esistente (e con la api di OpenWhisk si può fare, se la azione ha la API KEY configurata)

  3. Il menù deve essere moduficato per mostrare tutti i connettori disponibili, che io chiamereio iosdk/import, iosdk/import1etc

Nel mio libro è spiegato come fare a comunicare con le api, e qui c’è un codice che ho scritto (per altri scopi) che può creare azioni.

Potete usare già io-sdk per sviluppare la funzionalità per il momento.

#2

Io sarei disponibile per farlo tranquillamente,
Se ci sono altri volontari possiamo metterci d accordo.

Resto in attesa.

#3

No non ci sono altri volontari per questo task. Leonardo Cigolini mi ha detto che ha integrato le sue modifiche per la form. aspetto la sua PR e mergio il tutto.

Nel frattempo io lavorerei nel definire uno standard per il repo dei connettori. La prima idea era quella di indicizzare le releases di github ma non sono tanto convinto sia una buona idea.

Inoltre se mi dai il tuo nome github to aggiungo al progetto e ti assegno il task.

Invece ho pensato che si potrebbero usare le github pages, appoggiare tutti gli zip in un website e generare un file json index.json che elenca tutti i repo disponibili.

Che ne pensi?

#4

Per quanto riguarda github, il mio nome è sf3ris, come qua.

Secondo me entrambe le soluzione sono valide, gestire gli assets ad ogni release sicuramente è piu contorto delle github pages.

Le pages non le ho mai utilizzate in questo modo, si può provare tranquillamente. Non ci vedo grandi problemi di effort.

Si potrebbe fare un PoC in questo modo e vedere come viene.

Valerio.

#5

Ok ci possiamo coordinare anche se non so niente di connettori etc.

#6

Esatto. Se ti intendi di github actions puoi provarci tu, sennò ci penso io a fare una prova a pubblicare quello che abbiamo sulle gh-pages

#7

Qui si tratta di GitHub actions, il che significa buildare qualcosa e uploadarlo in una pagina GitHub e creare un indice in json. Qualcosa simile a quello che fa maven… molto in piccolo.

#8

Sisi ho capito il processo. Questa sera do un occhiata a come impostare questo processo automatico.

Ho visto che mi hai aggiunto alla repo github di io-gateway, la parte dei connettori la mettiamo li oppure su io-sdk ?

Per fare le prove con le pages mi serve anche l accesso alla repo dei connettori?

#9

Ovviamente ti devo dar accesso ad io-gateway-connectors, già fatto.

La roba da io-sdk la spostiamo su io-gateway asap, sto aspettando che @pfinocchiaro mi fa una bozza di docker-compose.

Notare che ho appena mergiato due altri connettori ora bisognerebbe fare appunto una formato per il repository dey connettory da mettere su ghpages.

#10

Sto seguendo questo flow per arrivare alla soluzione via github pages. Dimmi se logicamente mi sto sbagliando.

Ad ogni release della repo durante le github actions :

  • listare tutti i connettori con nome e filepath
  • creare un file json con nome e path per scaricare lo zip del connettore
  • creare i binary di ogni connettore
  • creare una folder per le gh-pages dove saranno contenuti :
    - index.json
    - connettori binari
#11

si esatto. la parte problematica è che i vari connettori hanno ambienti di build diversi, uno java uno python uno node etc… avevo pensato di fare una cosa modulare, separando le actions di build dei connettori da quella che crea l’indice.

qui l’esperto è @pierluigi.dilorenzo non ti creare problemi a chiedere se qualcosa non ti viene liscia.

#12

@msciab Ti aggiorno per lo sviluppo di questa task.
Per la parte dei connettori con la pubblicazione sulle GH pages, c’è la PR up.
Sono riuscito anche a creare un azione selezionando un connettore, a breve ti faccio la PR anche di questo.

Ora stavo pensando che la lista di connettori selezionati, che poi verranno mostrati sul menù dell’utente, dovremmo salvarli da qualche parte. Redis attualmente non è persistente o sbaglio?

Resto in attesa di maggiori informazioni.

Valerio.

#13

La funzionalita’ sarebbe per l’ IO-Gateway. L’ IO-SDK rimane, non ci sta ragione di “buttarlo via” e ha ancora casi d’uso, e non sarebbe difficile integrare il tutto sempliciemente aggiungendo al file di configurazione dei connettori binari da installare, ma il gateway avra’ persistenza. Lo deployamo in kubernetes con dei volumi. Il problema c’e’ anche per lo schedulatore che ha bisogno di un posto dove mantenere i dati. Ma per questo ti dicevo di lavorare a creare il repo, sto aspettando @pfinocchiaro che faccia una bozza del docker-compose per avere un ambiente di sviluppo pure per il gateway. Potrei farlo io ma mi sono dato come missione quello di far lavorare gli altri e lavorare per spiegare e integrare i pezzi piu’ che fare io le cose.

#14

Per la parte dei connettori, mantendendo la stessa repo abbiamo questa situazione qua, come si vede dal mio fork.

Credo fosse il risultato atteso oppure ho capito male qualche passaggio? :smile:
( Non fatevi problemi a dire che sono totalmente fuori strada, ogni critica è costruttiva )

Quindi per io-sdk la scelta dei connettori diciamo è statica, data da un file di config; Mentre per io-gateway è dinamica e selezionabile dall UI secondo la logica detto sopra. Giusto?

#15

Si e’ quello che intendevo. IO-SDK ha la sua logica che… non posso cambiare :smiley: senza che chi gia lo usa si infuri :slight_smile: l’ IO-Gateway, che in lontano futuro FORSE lo rimpiazzera’ (vedremo) sare un server da installare in un kubernetes e si devono poter installare connettori presi da un catalogo (a mo di pacchetti).

Quello che ho visto mi sembra corretto. Mi prendo un po’ di tempo per mergiare il tutto.

#16

Per la soluzione dinamica di io-getaway potrei andare avanti con la selezione dinamica e salvarli ( per ora) in redis e provare a fare un PoC della feature.

Per la soluzione con il config su io-sdk sarebbe da implementarlo durante lo start nella CLI scritta in GO? Potrei provare ma in GO non garantisco nulla, sono piuttosto acerbo :slight_smile:

#17

Puoi farlo sul l’sdk come funzuonalita di installazione plugin singolo e non persistente, Che è sempre utile, se nel gateway mettiamo la funzionalità multi plugin che sarà persistente. In generale non penso che butteemo via l’ IO-SDK perche’ parecchi lo stanno gia usando e quando si puo aggiungere qualcoa che ha senso mettere l’ SDK mettiamolo li. Un installer di binari e’ complementare a quello che gia fa l’ IO-SDK che permette di installare dai sorgenti ed editarli. Ma non penso valga la pena aggiungere la perrsostanza, dovremmo aggiungere un sacco di roba ed e’ meglio fare il tuttto nella versione server vera e propria con il docker compose e il kubernets.

L’ installer di plugin dovrebbe solamente essere in javascript, e per installare una azione lo puo’. fare una altra azione a patto che abbia l’ annotazione “expose api key”.

Tutto questo si puo fare semplicemente con una UI che elenca i plugin e invochi una chiamata “deploy”. Il deploy si puo’ fare con una azione che scarica l’azione e chiama la api per fare update.

Non serve Go.

#18

Con l’ultimo merge il mio ambiente di sviluppo (Windows 10 / wsl2 Ubuntu 20) non compila più (errori npm a partire da husky@4.3.4). Anche per questo, sto cercando di “dockerizzare” l’ambiente di sviluppo con vscode, penso sia meglio svincolarci dalle nostre macchine/sistemi preferiti: requisiti sarebbero solo docker e vscode (quest’ultimo solo per comodità). In sintesi è un Dockerfile (Ubuntu 18.04) che usa il docker sulla mia macchina tramite /var/run/docker.sock.

image
image1280×855 82.7 KB

Se può interessare, l’ultima versione si trova a


Non propongo ancora una PR perchè anche qui trovo degli errori e temo che solo @msciab possa aiutarmi: il make fallisce nella parte di test, per esempio 
iodev@dc518363dfb4:/app$ docker pull pagopa/iosdk-openwhisk:test
Error response from daemon: manifest for pagopa/iosdk-openwhisk:test not found: manifest unknown: manifest unknown

Visto che la action su github va a buon fine, forse le immagini sono riservate all’utente iosdk?

#19

da quel che vedo stai usando un branch test. ti serve un make build per costruire delle immagini taggate con quel branch. comunque nel devel.md quello che non legge nessuno ci sta scritto di usare make start che si preoccupa di creare le immagini giuste e di far partire il tutto con —skip-pull che evita di tentare di scaricare le immagini e usa quelle costruite localmente

#20

in che sensio ‘non compila più?’ la procedura sarebbe dineseguire ./setup.sh per scaricare tutto il necessario e siccome uso nodenv pyenv e goeenv tutte le dipendenze sono versionste fino all’ultimo bot. devi dare source source-me-first per attivare invari env. Se qualcosa simè scassato dovrebbe essere nel setup.sh .