[Python] Celery e autoscaling

[Karim]

Salve lista, ho fatto una domanda simile sulla lista django, ma penso che
sia opportuno fare la domanda anche qui dato che potrebbe essere un tipo di
problematica che puo' occorrere al di la' di Django.

Ho un applicazione python, nel processo di deploy ho celery lanciato da
supervisor e che usa un server Redis esterno. Il tutto lo gestisco con
ElasticBeanstalk di Amazon.

Ora vorrei creare delle nuove istanze (servers) in autoscaling, basandomi
sul fatto che ci sono x tasks in coda che aspettano di essere consumati dai
workers.

1) come faccio a controllare la coda dei workers con celery?

2) forse qualcuno di voi ha creato uno script che si basa sulla coda di
celery per fare scale in o scale out con l'autoscale di Amazon?

​Qualsiasi suggerimento/indicazione e' ben accetta.​

​Ciao
​

-- 
Karim N. Gorjux
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Dove pubblicare un sito in python (mantenendo anche il supporto a PHP)

[Karim]

Nessuno ha nominato AWS...

-- 
Karim N. Gorjux
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Dove pubblicare un sito in python (mantenendo anche il supporto a PHP)

[Esalando Prassi]

On 3 April 2017 at 22:06, Enrico Bianchi  wrote:
> On Thursday, March 30, 2017 8:41:19 AM CEST Esalando Prassi wrote:
>
>> ale@emily:~$ /usr/lib/python2.7/test/pystone.py
>
> File not found (e nemmeno sulla mia Fedora)
>

Come bug report non e' molto esaustivo.

Se vuoi te ne presto uno:

ale@emily:~$ locate pystone.py|wc -l
33

Ma secondo me questo ti basta:

- https://svn.python.org/projects/python/trunk/Lib/test/pystone.py

Ciao.
-- 
http://alepisa.blogspot.com
Esalando Prassi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Dove pubblicare un sito in python (mantenendo anche il supporto a PHP)

[Enrico Bianchi]

On Thursday, March 30, 2017 8:41:19 AM CEST Esalando Prassi wrote:

> ale@emily:~$ /usr/lib/python2.7/test/pystone.py

File not found (e nemmeno sulla mia Fedora)

Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Scelta GUI

[Gollum1]

Il 3 aprile 2017 08:37:11 CEST, Giovanni Porcari  
ha scritto:
>
>Con l'occasione estendo agli altri lettori della lista lo stesso
>invito:
>se credete di poter contribuire allo sviluppo di Genropy fatemelo
>sapere
>e sarete i benvenuti.
>

Arruolato d'ufficio... 

-- 
Gollum1
Teoro, dov'è il mio teoro...

Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
errori (maledetto correttore ortografico).
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Scelta GUI

[Gollum1]

Il 3 aprile 2017 01:01:53 CEST, Enrico Bianchi  ha 
scritto:
>On 03/30/2017 06:58 AM, Giovanni Porcari wrote:
>> Noi non cerchiamo manovalanza ma consigli e suggerimenti.
>Un po' di considerazioni le ho tirate, spero che possano essere utili
>

Lo sarà sicuramente per il progetto di genropy, ma lo è sicuramente per me 
personalmente, non ho mai affrontato il problema della gestione dei miei 
progetti, uso il bitbucket più come archivio per non perderlo, e per poterci 
lavorare indifferentemente da diversi posti. Farò tesoro dei tuoi consigli.

Grazie.

-- 
Gollum1
Teoro, dov'è il mio teoro...

Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli 
errori (maledetto correttore ortografico).
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Scelta GUI

[Giovanni Porcari]

> Il giorno 03 apr 2017, alle ore 01:01, Enrico Bianchi 
>  ha scritto:
> 
> On 03/30/2017 08:37 AM, Gollum1 wrote:
>> In che modo dovrebbe essere gestito un repository di sviluppo?
> Partiamo da un presupposto: queste sono mie considerazioni basate da 
> quanto ho visto in giro e da come mi regolo io nel gestire un 
> repository. Analizzando il repository BitBucket di Genropy:
> 
> Commit:
> Per come la vedo io, un commit dovrebbe essere riferito ad un solo 
> evento, ovvero mai riferirsi a due modifiche differenti. Per capirci, un 
> commit che incorpora un fix e che incorpora una modifica di sviluppo non 
> deve esistere. Inoltre, per me i commit dovrebbero essere il più 
> granulari possibile, anche riferiti al cambio di una sola linea di 
> codice (git da questo punto di vista aiuta parecchio, essendo 
> decentralizzato). Questo perché non solo è più facile capire 
> l'evoluzione del codice, ma è anche più facile eseguire operazioni di 
> rebase o di cherry-pickying. Da quello che ho visto (un paio di commit, 
> in realtà), in Genropy vengono incorporati i commit, cosa che come ho 
> detto per me è Male™
> 
> Branch[1]:
> Partiamo da un presupposto, esistono due tipi di branch: quelli di 
> sviluppo di funzionalità (i feature branch) e quelli di 
> mantenimento/hotfix del prodotto. La differenza è semplice: i primi sono 
> branch che nascono per una deviazione dello sviluppo e muoiono, mediante 
> merge o mediante cancellazione, quando questa deviazione finisce. 
> Inoltre, molti li usano per definire dei workflow differenti da quello 
> standard[2][3]. Da quello che mi è sembrato di capire, in Genropy viene 
> usato un workflow basato su di un branch di sviluppo/feature/hotfix, ma 
> mi sembra che ci siano anche dei branch che non c'entrano nulla con 
> tutto il resto. Ora, le motivazioni possono essere due: o i branch in 
> più sono di funzionalità che sono rimasti per storico o per mancata 
> cancellazione, o sono deviazioni dallo sviluppo principale per 
> customizzazioni specifiche. Nel primo caso, vedo un peccato "veniale", 
> ovvero semplicemente non è stata fatta pulizia del repository, mentre 
> nel secondo vedo un peccato più grave perché ogni customizzazione non 
> riportata nel ramo principale significa non solo che ogni fix dev'essere 
> riportato su tutti i branch, ma che c'è una gestione malsana del 
> progetto, quindi spero che il progetto non si trovi in quest'ultimo caso.
> 
> Tag:
> Qua vedo non è che ci sia molto da dire, per come l'ho intesa io i tag 
> in Genropy sono usati alla stregua di branch. Comunemente i tag in 
> qualsiasi sistema di controllo di revisione vengono usati per rilasciare 
> la nuova versione del software, tanto che basta vedere il repository di 
> un qualsiasi altro software per notare questa convenzione e che molti 
> software di supporto li gestiscono in tal senso (e.g. Github rilascia 
> automaticamente una versione del tuo software non appena compare il 
> tag). Va da sè che è qua che per me, quello che fino a sopra era 
> sopportabile (mi si perdoni il termine), diventa inaccettabile. Non vedo 
> un senso alla gestione dei tag, e quindi non è chiaro quanto e come si 
> sta evolvendo il software.
> 
> Per quanto riguarda il repository Github, invece, posto che sono 
> d'accordo con le osservazioni dell'issue aperta, quello che vedo è non 
> solo la mancanza di tag (che aiuterebbe non poco), ma uno scarso 
> utilizzo del mezzo. Per intenderci, per quanto anche io sia un 
> estimatore di BitBucket, Github permette di avere più visibilità 
> rispetto a qualsiasi altro sistema di gestione dei repository, pertanto 
> considererei veramente una migrazione del repository di sviluppo.
> 
> In definitiva, allo stato attuale quello che farei è questo:
> 
>  - Rivedrei tutti i tag utilizzando un sistema di versioning 
> esplicativo[4] rispetto all'attuale.
>  - Eliminerei tutti i branch morti, più per pulizia che altro.
>  - Ristrutturerei il repository utilizzando come tracce di esempio [2] 
> o [3], visto che ben si adattano al workflow che si sta utilizzando in 
> questo momento
> 
> Enrico
> [1] A tal proposito, consiglio sempre di seguire questo: 
> http://learngitbranching.js.org/ 
> [2] http://nvie.com/posts/a-successful-git-branching-model/
> [3] https://about.gitlab.com/2014/09/29/gitlab-flow/
> [4] http://semver.org/


Caro Enrico

ti ringrazio davvero tanto per questa risposta davvero completa 
e per il tempo che ci hai dedicato per analizzare i repository.
Proprio in questo momento stiamo partendo con un profondo lavoro di revisione
che va in questa direzione. Come spesso ho detto siamo un piccolo gruppo con 
troppo
lavoro e troppi pochi soldi per finanziarlo e quindi quando vedo che ci sono
persone come te contribuiscono non con critiche sterili ma con consigli e
offrendo contributi in base alla loro esperienza capisco come sia importante
agire per avere il tipo di esperienza di uso che le