Provide a dockerfile to ease deployment

The admin dashboard page is empty

Riassumo, in ordine, quanto ho inteso riguardo il ruolo degli utenti e lo stato di implementazione:

• Gli utenti sono solo un mezzo di gestione delle risorse del server e quindi, benche' i lavori (e la relativa coda) sono "posseduti" dal relativo utente, i risultati sono "pubblici". Questi account sono quindi da considerarsi come per "uso interno": non richiedono quindi che venga fatto tutto il processo di registrazione/verifica-della-mail ma vengono invece creati da un admin e dati "a mano" ad una o piu' persone (uso "libertino" degli account).

Al momento gli utenti sono implementati come segue:

• C'e' un account di super-admin con credenziali "hardcoded" nel codice: in questo modo questo account non e' alterabile da dentro il sistema (non puo' essere cancellato da un altro admin ad esempio) e viene preservato anche in caso di perdita/irraggiungibilita' del db. Rimane da decidere se mantenere le credenziali nel file o metterle come variabile d'ambiente (la seconda soluzione e' quella ritenuta comunemente come la migliore delle due ma (forse) potrebbe complicare il deploy nel caso in cui ad esempio ruby venga lanciato da un altro utente).

La struttura:

• nickname : Puo' essere una email ma non necessariamente
• password : Nell'ottica di 'uso interno' la salverei in chiaro perche' la considererei un segreto condiviso con chi ha dato l'account all'utente, in contrapposizione ad altre forme di account dove la password e' un segreto privato dell'utente
• email : Dove notificare l'utente del lavoro completato.
• max_cpu_t : Massimo tempo CPU che un processo di questo utente puo' impiegare prima di essere terminato.
• max_fs : Dimensione massima dei file che l'utente puo' caricare.
• max_ql: Massimo numero di lavori che un utente puo' accodare.
• enabled : Un account puo' essere bloccato.

TODO:

• Rimuovere l'utente integrato e stabilire una procedura per l'introduzione del primo utente e limitarne la gestione.
• Togliere la possibilita' di eliminare utenti
• Tenere traccia delle modifiche effettuate ad un utente (nick / email)

The pinw-fetch.rb program gives the following error:

/var/lib/gems/2.2.0/gems/sqlite3-1.3.10/lib/sqlite3/database.rb:91:in `initialize': SQLite3::SQLException: no such table: settings: SELECT  "settings".* FROM "settings"  WHERE "settings"."key" = 'MAX_ACTIVE_DOWNLOADS' LIMIT 1 (ActiveRecord::StatementInvalid)
        from /var/lib/gems/2.2.0/gems/sqlite3-1.3.10/lib/sqlite3/database.rb:91:in `new'
        from /var/lib/gems/2.2.0/gems/sqlite3-1.3.10/lib/sqlite3/database.rb:91:in `prepare'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/sqlite3_adapter.rb:301:in `block in exec_query'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract_adapter.rb:373:in `block in log'
        from /var/lib/gems/2.2.0/gems/activesupport-4.1.8/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract_adapter.rb:367:in `log'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/sqlite3_adapter.rb:298:in `exec_query'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/sqlite3_adapter.rb:510:in `select'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/database_statements.rb:24:in `select_all'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/querying.rb:39:in `find_by_sql'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/relation.rb:611:in `exec_queries'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/relation.rb:493:in `load'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/relation.rb:238:in `to_a'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/relation/finder_methods.rb:460:in `find_take'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/relation/finder_methods.rb:98:in `take'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/relation/finder_methods.rb:81:in `find_by'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/relation.rb:215:in `find_or_create_by!'
        from /var/lib/gems/2.2.0/gems/activerecord-4.1.8/lib/active_record/querying.rb:6:in `find_or_create_by!'
        from /home/app/pinw/models/settings.rb:7:in `_get_or_create_max_active_downloads'
        from /home/app/pinw/models/settings.rb:16:in `get_max_active_downloads'
        from /home/app/pinw/cron/pinw-fetch.rb:104:in `initialize'
        from /home/app/pinw/cron/pinw-fetch.rb:699:in `new'
        from /home/app/pinw/cron/pinw-fetch.rb:699:in `<main>'

Incollo direttamente il codice di ActiveRecord, mi sembra abbastanza autoesplicativo:

create_table :servers do |table|
      table.column :priority,     :integer           
      table.column :name,     :string, null: false           
      table.column :host,     :string, null: false           
      table.column :port,     :string
      table.column :username, :string, null: false


      table.column :password,           :string
      table.column :client_certificate, :string
      table.column :client_passphrase,  :string       

      table.column :pintron_path,   :string             
      table.column :python_command, :string         
      table.column :working_dir,      :string            

      table.column :use_callback,  :boolean, default: true
      table.column :callback_url,  :string            

      table.column :local_network, :boolean, default: true

      table.timestamps

      table.column :enabled,       :boolean, default: true      

      table.index :name, unique: true
      table.index :priority, :unique => true
    end

• Il primo gruppo di proprieta' e' quello standard.
• Il secondo e' l'autenticazione (password o chiave privata).
• Il terzo e' una bozza delle configurazioni specifiche del server che possono essere necessarie.
• Il quarto e' la configurazione della calback http: quando un server ha terminato un processo puo' notificarlo al server web tramite questo meccanismo. Puo' essere disabilitato o configurato un url particolare in caso di configurazioni barocche.
• Il quinto gruppo e' una spunta per specificare se il server si trova in una rete locale oppure no: viene usato per poter gestire un limite di consumo della linea per il trasferimento webserver <-> worker per evitare di rendere il webserver irraggiungibile.
• Infine timestamp e flag di abilitazione.

Mancano dei campi relativi allo stato del server all'ultimo controllo, che andro' ad aggiungere quando scrivo la parte di dispatch dei cron.

Ci sono osservazioni?

Please move the current master branch into another branch and make pinw-sinatra the new master

The "last results" icon and the menu icon have not the same height.

When creating a new job, add an option to send an email when the job has finished.

rake aborted!
SyntaxError: /home/app/pinw/routes/base.rb:38: syntax error, unexpected keyword_end
/home/app/pinw/routes/base.rb:49: syntax error, unexpected end-of-input, expecting keyword_end
/home/app/pinw/main.rb:60:in require_relative' /home/app/pinw/main.rb:60:in<top (required)>'
/home/app/pinw/Rakefile:2:in `<top (required)>'

Please relax the constraints on the gem versions, so that the application can be deployed on Ubuntu 14.04LTS (Sinatra 1.4.3, activerecord 4.0.2), if possible.
Alternatively, allow deployment with Ubuntu 14.10 (activerecord 4.1.4).

Dunque sui Job avrei diverse domande.

Inizio descrivendo come l'ho modellato al momento:

• _campi con i dati di input_: (genomica, FASTQ) in base a dove vengono presi (ensembl/file, dropbox/upload/altro), i trascritti da tradurre in JSON, la soglia di qualita'.
• user_id: l'utente che ha creato il job
• server_id: ogni job viene eseguito su un server, i server sono altri oggetti per cui poi apro un altra issue
• status: i vari stati come ad esempio QUEUED, RUNNING, COMPLETED, FAILED
• _date varie_: data creazione, data in cui e' partito il processo, data di conclusione
• result_id: oggetto contenente i risultati creato quando il job ha esito positivo

Al momento pensavo di usare due tipi diversi di oggetti/tabelle/relazioni per rappresentare i job ed i risultati e di replicare alcuni dei campi sopraelencati in questi ultimi cosi' da poter liberamente eliminare i job senza dover implementare regole complicate di consistenza e senza perdere informazioni.

Le domande:

• Come gestire i vari fallimenti possibili? Ad esempio: se ensembl va offline e non riesco a recuperare i trascritti?
• Nel processamento che fallimenti possono accadere? Possono essere correggibili? (implicherebbe la possibilita' di modificare un job fallito per rimetterlo in coda)
• Sarebbe utile permettere all'utente di decidere su quale server far andare un job? Se admin?
• Se implemento io una logica di loadbalancing, come decido di fare il bilanciamento? (ad esempio: se il processamento non e' parallelizzato e' possibile definire un numero massimo di processi attivi contemporaneamente). Non pretendo una risposta completa ma ho bisogno di sapere altri dettagli di cosa succede nel server di lavoro per poter fare un design sensato.

Use sphinx and readthedocs.org for documentation, instead of a wiki.

Pintron path field missing in schema

The command RACK_ENV=production rake db:setup gives the following error:

NoMethodError: undefined method `password_digest=' for #<User:0x0000000346fd18>
/usr/local/rvm/gems/ruby-2.2.5/gems/activemodel-4.1.6/lib/active_model/attribute_methods.rb:435:in `method_missing'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/attribute_methods.rb:211:in `method_missing'
/usr/local/rvm/gems/ruby-2.2.5/gems/activemodel-4.1.6/lib/active_model/secure_password.rb:112:in `password='
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/attribute_assignment.rb:45:in `public_send'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/attribute_assignment.rb:45:in `_assign_attribute'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/attribute_assignment.rb:32:in `block in assign_attributes'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/attribute_assignment.rb:26:in `each'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/attribute_assignment.rb:26:in `assign_attributes'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/core.rb:455:in `init_attributes'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/core.rb:198:in `initialize'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/inheritance.rb:30:in `new'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/inheritance.rb:30:in `new'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/validations.rb:39:in `create!'
db/seeds.rb:4:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.2.5/gems/activesupport-4.1.6/lib/active_support/dependencies.rb:241:in `load'
/usr/local/rvm/gems/ruby-2.2.5/gems/activesupport-4.1.6/lib/active_support/dependencies.rb:241:in `block in load'
/usr/local/rvm/gems/ruby-2.2.5/gems/activesupport-4.1.6/lib/active_support/dependencies.rb:232:in `load_dependency'
/usr/local/rvm/gems/ruby-2.2.5/gems/activesupport-4.1.6/lib/active_support/dependencies.rb:241:in `load'
/usr/local/rvm/gems/ruby-2.2.5/gems/sinatra-activerecord-2.0.3/lib/sinatra/activerecord/rake/activerecord_4.rb:4:in `load_seed'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/tasks/database_tasks.rb:184:in `load_seed'
/usr/local/rvm/gems/ruby-2.2.5/gems/activerecord-4.1.6/lib/active_record/railties/databases.rake:174:in `block (2 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.2.5/bin/ruby_executable_hooks:15:in `eval'
/usr/local/rvm/gems/ruby-2.2.5/bin/ruby_executable_hooks:15:in `<main>'

According to this article the users table needs a password_digest field.

Is it possible to add an action to delete a user?

• Swap download and processing indicators
• Hide download indicators once download phase is completed
• Add a 'my latest results' button in the job history page
• Fuse dispatch and processing steps in the progressbar
• Better defaults and phrasing
• Quality ts slider with explicit value
• Add 'created at' for each job
• Remove 'unknown' flag from form

The label of the last results summary (on the left) is always "asd".
It should be the Name of gene (and the description if possible).

Close to the save button, add import and export buttons so that settings can be backupped and restored if needed.
It is especially useful in the case of docker containers, since a container shutdown deletes all settings

When clicking on the Human:BRCA2 results,

the results of the ATP6AP1 gene are shown instead.

What is the initial admin user/password?