Guide du développeur MetPX-Sarracenia
- version:
3.00.57rc0
- date:
Nov 18, 2024
Outillage
Pour contribuer à la source Sarracenia, vous avez besoin de:
Un environnement de développement Linux, soit un poste de travail, soit une machine virtuelle quelconque. La configuration à l’aide d’Ubuntu est automatisée, mais un ajustement pour d’autres distributions est possible. Le confort en ligne de commande est un must.
python3. L’application est développée en Python et dépend des versions python >= 3.6.
style: PEP8 sauf que la longueur maximale de la ligne est de 119, appliquée via pycodestyle pour VSCode, yapf3 ou un autre outil similaire.
Un compte sur github.com aidera à soumettre des patches.
Les éléments qui seront installés par configuration automatisée :
un tas d’autres modules python indiqués dans les dépendances (setup.py ou debian/control)
Module Pyftpdlib python3, utilisé pour exécuter un serveur ftp sur un port élevé pendant le test de flux.
git. afin de télécharger la source à partir du dépôt GitHub, et de préparer et soumettre changements.
Un courtier RabbitMQ dédié, avec accès administratif, pour exécuter les tests sr_insects. Ceci est installé par des outils automatisés pour configurer l’environnement Linux. Le test de flux crée et détruit les échanges et perturbera tous les flux actifs sur le courtier.
après avoir cloné le code source:
git clone -b development https://github.com/MetPX/sarracenia sr3
git clone -b development https://github.com/MetPX/sarrac metpx-sr3c
git clone https://github.com/MetPX/sr_insects insects
cd sr3
Le reste du guide suppose que vous y êtes.
Documentation
Normes de documentation existent dans /docs/Contribution/Documentation.rst. Le processus pour la construction locale des documents sont là, ainsi que les méthodes de maintenance du site Web en direct.
Où documenter les options
Les options sont documentées dans le style de dictionnaire sr3_options(7) par ordre alphabétique. Si cela en valait la peine, des exemples d’utilisation pourraient être ajoutés à d’autres guides.
Développement
En général, le flux de travail de développement consiste à obtenir un ordinateur portable ou une machine virtuelle où l’on peut exécuter les flow_tests (disponible auprès de http://github.com/MetPX/sr_insects ). La première étape lors de la configuration d’un environnement de développement s’agit de s’assurer que les tests de flux sr_insects fonctionnent, car ils fonctionnent comme une porte d’entrée pour les commits dans les branches importantes.
Le développement est le plus souvent effectué sur la plate-forme Ubuntu > = 18.04.
Flux de travail v2
Le travail de développement terminé pour la version 2 est engagé sur la branche v2_dev, qui est utilisée pour produire des instantanés quotidiens. On ne devrait normalement pas engager de changements dans la direction v2_dev, mais plutôt les fusionner à partir d’une branche de travail.
Les directions générales du développement sont nommées d’après la question qu’elles sont censées aborder “v2_issue365”, par exemple. S’il y a plusieurs tentatives pour résoudre un problème donné, utilisez le problème comme préfixe de nom. Par exemple, il pourrait y avoir issue365, mais si nous décidons que ce n’est pas une bonne façon d’aborder le problème, il pourrait y avoir une direction issue365_methodB.
Avant de soumettre une demande d’extraction (Pull Request, PR), veuillez vous assurer que les tests de flow de sr_insects ont été exécutés avec succès : au moins static_flow, flakey_broker et dynamic_flow
Lorsqu’un PR est généré, le deuxième développeur peut l’examiner pour détecter des préoccupations. Une fois satisfait de la nature du correctif, le deuxième développeur doit retirer la branche et exécutez à nouveau les tests de flux (les trois mêmes) pour confirmer. Seulement après que les tests de flux ont été exécutés sur plusieurs machines qu’on peut ensuite fusionner avec stable.
Les problèmes propres à la v2 doivent être étiquetés v2only. sur Launchpad.net :
Les paquets de référentiel quotidiens de v2 seront construits à partir de v2_dev
Les paquets de référentiel de pré-version de v2 seront construits à partir de v2_dev
Les packages de référentiel de versions sont générés à partir de v2_stable.
Flux de travail v3
La prochaine version de Sarracenia est développée dans la branche development (travail en cours). Comme la refactorisation majeure est pratiquement terminée, le travail restant est maintenant entièrement constructif et tout le développement est coordonné par des issues exactement comme l’est la V2. Les problèmes propres à la v3 sont les régressions ou améliorations qui n’ont pas de sens à ajouter à v2, ont la balise v3only. Les problèmes communs entre les versions sont marqués v3.
Le flux de travail avec v3 est similaire à v2 mais avec des branches différentes. Avoir tous les tests de flux complétés avec assez de succès est un des critères d’acceptation dans development.
Pour exécuter les tests sr_insects, le référentiel doit être cloné avec la branche development. Une porte pour la fusion à development est pour un deuxième développeur d’exécuter le flow_tests. Pour la v03, ces tests doivent exécuter : static_flow, flakey_broker, dynamic_flow, transform_flow
Prévu d’ici le 11/04/2022:
Main sera fusionné à partir de development, donc la branche par défaut pour les nouveaux arrivants sera SR3.
Launchpad aura de nouvelles recettes pour produire des paquets SR3 à partir de la branche principale.
sr_insects
Le référentiel sr_insects a sa propre base de données de problèmes, et le travail sur sr_insects est encouragé. Les versions 2 et 3 sont prises en charge sur la branche principale de sr_insects. Cette branche devrait être utilisé pour prendre en charge tout le développement dans les deux versions…
Tests unitaires
Le sous-répertoire tests/ contient un ensemble malheureusement incomplet mais croissant de tests unitaires qui utilisent le framework pytest. Ces tests requiert Ubuntu 22.04 pour le moment. Consultez tests/README.md pour savoir comment les exécuter. Réussite des tests unitaires (ou une très bonne explication pourquoi ils échouent temporairement) devrait être une autre porte avant de fusionner avec la branche developpement principale.
Installation locale
Il existe de nombreuses façons d’installer des paquets python sur un ordinateur. Différents développeurs préféreront différentes méthodes, et toutes les méthodes doivent être testées avant chaque version. Avant d´installer le paquet il faut généralement une librarie pour communiquer avec le courtier de messages (généralement rabbitmq/AMQP, mais ca peut être MQTT également)
Wheel Lorsque les gens utilisent différents systèmes d’exploitation (non-Ubuntu, non-Debian), les gens installent des wheel, généralement qui ont été téléchargées sur pypi.python.org. D’un autre côté, c’est un peu pénible / bruyant de télécharger chaque version de développement, donc nous ne téléchargeons que des versions, donc les tests de wheel se font en construisant des roues locales. Besoin de construire une nouvelle wheel chaque fois qu’un changement est apporté. pip install amqp sera également nécessaire pour le support rabbitmq.
pip install (pas -e) tirerait une wheel vers le bas de pypi.python.org. Généralement pas utilisé pendant le développement de Sarracenia lui-même. pip install amqp sera également nécessaire pour le support rabbitmq.
pip install -e … vous permet de modifier le code source du package installé, idéal pour les problèmes de débogage, car il permet des modifications en direct de l’application sans avoir à passer par la construction et l’installation d’un nouveau package. pip install amqp sera également nécessaire pour le support rabbitmq.
apt install installer le paquet Debian à partir de dépôts, de la même manière que pip install (pas -e), normalement les instantanés de développement ne sont pas téléchargés vers des dépôts, donc bien que ce soit la manière normale pour les utilisateurs de serveurs Ubuntu, il n’est pas disponible pendant le développement du paquet lui-même. apt install python3-amqp sera également nécessaire pour le support rabbitmq.
dpkg -i construit un paquet Debian pour l’installation locale. C’est ainsi que les packages sont testés avant d’être téléchargés vers des référentiels. Il peut également être utilisé pour soutenir le développement (il faut exécuter dpkg -i pour chaque changement de paquet). apt install python3-amqp sera également nécessaire pour le support rabbitmq.
Le test sr_insects appelle la version de metpx-sarracenia installée sur le système, et non ce qui est dans l’arbre de développement. Il est nécessaire d’installer le paquet sur le système afin qu’il exécute les tests sr_insects.
Préparer une machine virtuelle Vanilla
Cette section décrit la création d’un environnement de test à utiliser dans un ordinateur virtuel. Une façon de construire une machine virtuelle est d’utiliser Multipass (https://multipass.run) En supposant que ce soit installé, on peut crée une machine virtuelle avec
multipass launch -m 8G -d 30G --name flow
Vous devez faire fonctionner SSH LocalHost dans le conteneur MultiPass. Peut le faire en copiant la clé privée multipasse dans le conteneur:
fractal% multipass list
Name State IPv4 Image
primary Stopped -- Ubuntu 20.04 LTS
flow Running 10.23.119.56 Ubuntu 20.04 LTS
keen-crow Running 10.23.119.5 Ubuntu 20.04 LTS
fractal%
Problèmes étranges avec les clés ssh qui ne sont pas interprétées correctement par paramiko, solution de contournement, ( https://stackoverflow.com/questions/54612609/paramiko-not-a-valid-rsa-private-key-file )
fractal% sudo cat /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa | sed 's/BEGIN .*PRIVATE/BEGIN RSA PRIVATE/;s/END .*PRIVATE/END RSA PRIVATE/' >id_rsa_container
chmod 600 id_rsa_container
scp -i id_rsa_container id_rsa_container ubuntu@10.23.119.175:/home/ubuntu/.ssh/id_rsa
100% 1704 2.7MB/s 00:00
fractal% scp -i id_rsa_container id_rsa_container ubuntu@10.23.119.106:/home/ubuntu/.ssh/id_rsa
The authenticity of host '10.23.119.106 (10.23.119.106)' can't be established.
ECDSA key fingerprint is SHA256:jlRnxV7udiCBdAzCvOVgTu0MYJR5+kYzNwy/DIhkeD8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.23.119.106' (ECDSA) to the list of known hosts.
id_rsa_container 100% 1712 9.4MB/s 00:00
fractal% multipass shell flow
Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-81-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Fri Aug 27 21:12:16 EDT 2021
System load: 0.42 Processes: 112
Usage of /: 4.4% of 28.90GB Users logged in: 0
Memory usage: 5% IPv4 address for ens4: 10.23.119.106
Swap usage: 0%
1 update can be applied immediately.
To see these additional updates run: apt list --upgradable
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
ubuntu@flow:~$
Invitez ensuite SSH à accepter la clé localhost:
ubuntu@flow:~$ ssh localhost ls -a
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:jlRnxV7udiCBdAzCvOVgTu0MYJR5+kYzNwy/DIhkeD8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
.
..
.bash_logout
.bashrc
.cache
.profile
.ssh
ubuntu@flow:~$
Cela fournira un shell dans une machine virtuelle initialisée. Pour le configurer:
git clone -b development https://github.com/MetPX/sarracenia sr3
cd sr3
Il existe des scripts qui automatisent l’installation de l’environnement nécessaire pour pouvoir exécuter des tests:
travis/flow_autoconfig.sh
travis/add_sr3.sh
ous devriez pouvoir voir une configuration vide:
sr3 status
SR3C et SR3 sont maintenant installés et devraient être prêts à exécuter un test de débit à partir du module sr_insects, qui a également été cloné
cd ../sr_insects
La branche v03 de sr_insects prend en charge les tests des versions 2 et 3, et les deux versions sont maintenant installées. Les tests de flux sont destinés à être exécutés pour confirmer la compatibilité entre v2 et v3, et donc doivent également pouvoir tester la V2
ubuntu@flow:~/sr_insects$ dpkg -l | grep metpx
ii metpx-libsr3c 3.21.08a1-0~202108270410~ubuntu20.04.1 amd64 C-Implementation of a Sarracenia Client
ii metpx-sarracenia 2.21.08-0~202108241854~ubuntu20.04.1 all Directory mirroring in real-time for users, file servers and web sites.
ii metpx-sr3 3.00.008exp all v3 Directory mirroring in real-time for users, file servers and web sites.
ii metpx-sr3c 3.21.08a1-0~202108270410~ubuntu20.04.1 amd64 C-Implementation of a Sarracenia Client
ubuntu@flow:~/sr_insects$
Le paquet v2 est metpx-sarracenia, tandis que le paquet v3 est metpx-sr3. Les tests de débit détecteront quelle version est installée et testera v3 si les deux sont présents. Pour remplacer cela
ubuntu@flow:~/sr_insects$ export sarra_py_version=2.21.08
ubuntu@flow:~/sr_insects$
Ensuite, on peut exécuter flow_tests à partir de ce shell normalement.
Python Wheel
Si vous n’avez pas utilisé add_sr3.sh (qui construit un paquet debian), alors on peut utiliser cette procédure Pour une installation locale sur un ordinateur avec un Python Wheel pour les tests et le développement:
python3 setup.py bdist_wheel
ou… Sur les systèmes plus récents, utilisez build à la place
python3 -m build --no-isolation
Doit construire un Wheel dans le sous-répertoire dist. Ensuite, en tant que root, installez ce nouveau paquet:
pip3 install --upgrade ...<path>/dist/metpx*.whl
Pip install locale
Pour une installation locale sur un ordinateur, à l’aide d’un pip. Pour les tests et le développement:
pip3 install -e .
export PATH=${HOME}/.local/bin:${PATH}
Utilisation du programme d’installation du package python local (PIP) pour créer une version modifiable localement. Le code en dessus installera le paquet dans ~/.local/bin… Il faut donc s’assurer que le chemin comprend ce répertoire.
Debian/Ubuntu
Pour une installation locale sur un ordinateur, en utilisant un paquet debian. Ce processus construit un .deb local dans le répertoire parent en utilisant les mécanismes Debian standard.
Vérifiez la ligne build-depends dans debian/control pour les dépendances qui pourraient être nécessaires pour construire à partir de source.
Les étapes suivantes feront un build de sarracenia mais ne signeront pas les modifications ou le paquet source
cd metpx/sarracenia sudo apt-get install devscripts debuild -uc -us sudo dpkg -i ../<the package just built>
qui accomplit la même chose en utilisant l’empaquetage Debian. Les options sont détaillées ci-dessous :
Commit de Code
Que faut-il faire avant de s’engager dans la branche principale? Liste de contrôle:
faire du développement sur une autre branche. Habituellement, la branche sera nommée d’après le problème adressée. Exemple : issue240. Si nous abandonnons une approche initiale et en commençons une autre, il peut y avoir issue240_2 pour une deuxième tentative. Il peut également y avoir des branches de fonctionnalités, telles que v03.
Les tests sr_insects fonctionnent (Voir Tests) La branche principale doit toujours être fonctionnelle, ne validez pas de code si les tests sr_insects ne fonctionnent pas.
Conséquence naturelle : si les changements de code signifient que les tests doivent changer, incluez le changement de test dans le commit.
Mettre à jour la doc/ Les pages de manuel devraient idéalement recevoir leurs mises à jour en même temps que le code.
Habituellement, il y aura beaucoup de cycles de ce type sur une branche de développement avant que l’un d’eux ne soit prêt à émettre une pull request. Finalement, nous arrivons à Commits vers la branche principale
Description des Tests sr_insects
Avant de valider du code dans la branche principale, en tant que mesure d’assurance qualité, il faut exécuter tous les autotests disponibles. On suppose que les modifications spécifiques apportées au code ont déjà passé les tests unitaires. Veuillez ajouter des autotests appropriés à ce processus pour refléter les nouveaux. D’une manière générale, il faut résoudre les problèmes au premier test qui échoue parce que chaque test est plus compliqué que le précédent.
Il existe un dépôt git séparé contenant les tests les plus complexes https://github.com/MetPX/sr_insects
Un flux de travail de développement typique sera (N’essayez pas ceci, ceci est juste un aperçu des étapes qui seront expliqué en détail dans les sections suivantes)
git branch issueXXX
git checkout issueXXX
cd sarra ; *make coding changes*
cd ..
debuild -uc -us
cd ../sarrac
debuild -uc -us
sudo dpkg -i ../*.deb
cd ..
git clone -b development https://github.com/MetPX/sr_insects
cd sr_insects
sr3 status # make sure there are no components configured before you start.
# test results will likely be skewed otherwise.
for test in unit static_flow flakey_browser transform_flow dynamic_flow; do
cd $test
./flow_setup.sh # *starts the flows*
./flow_limit.sh # *stops the flows after some period (default: 1000) *
./flow_check.sh # *checks the flows*
./flow_cleanup.sh # *cleans up the flows*
cd ..
done
#assuming all the tests pass.
git commit -a # on the branch...
Unit
Le test unitaire dans sr_insects est le plus court qui prend environ une minute et ne nécessite pas beaucoup de configuration. Ce sont des tests de santé mentale du comportement du code. Prend généralement une minute ou deux sur un ordinateur portable.
Static Flow
Les tests static_flow sont un peu plus compliqués, testant plus de composants, utilisant un seul composants monothread de manière linéaire (toutes les données avancent uniformément.) Il devrait être plus simple pour identifier les problèmes car il n’y a pas de suppression et donc cela se prête bien à répéter des tests de sous-ensembles pour identifier les problèmes individuels. Cela prend environ deux minutes sur un ordinateur portable.
Flakey Broker
Les tests flakey_broker sont les mêmes que les static_flow, mais ralentis de sorte qu’ils durent quelques minutes de plus, et le courtier est arrêté et redémarré pendant que la publication se produit. Notez que post_log imprime avant qu’un message de notification ne soit publié (parce que post_log est un plugin on_post, et cette action, permet de modifier le message de notification, donc il doit être avant que la publication ne se produise réellement.)
Dynamic Flow
Le test dynamic_flow ajoute des fonctionnalités avancées : multi-instances, le composant winnow, les tests logiques de nouvelle tentative, et inclut également les suppressions de fichiers. La majeure partie de la documentation ici fait référence à l’exécution du dynamic_flow test, car c’est le plus compliqué, et l’ancêtre des autres. Le test unitaire a été séparé du début du test dynamic_flow, et le static_flow est une version simplifiée du test de flux original.
D’une manière générale, il convient d’exécuter les tests en séquence et de s’assurer que les résultats des tests antérieurs soient sont bons avant de passer aux tests suivant.
Notez que le système de développement doit être configuré pour que les tests sr_insects s’exécutent correctement. Voir la suite pour les instructions de configuration. Pour le développement avec une nouvelle installation du système d’exploitation, les étapes de configuration ont été automatisées et peuvent être appliquées avec le flow_autoconfig.sh dans sr_insects (https://github.com/MetPX/sr_insects/blob/stable/flow_autoconfig.sh). L’exécution à l’aveugle de ce script sur un système fonctionnel peut entraîner des effets secondaires indésirables; vous êtes prévenus !
La configuration que l’on essaie de répliquer :
Le tableau suivant décrit ce que fait chaque élément du test de flux dynamique, et la couverture du test montre les fonctionnalités couvertes.
Configuration |
Fait |
Couverture du test |
subscribe t_ddx |
copy from data mart to local broker posting notification messages to local xwinno00 and xwinnow01 exchanges. |
lit le data mart public amqps (v02) comme utilisateur ordinaire. fil d’attente partagé et plusieurs processus 3 instances téléchargent de chaque q poster amqp à un échange local (v02) en tant qu’utilisatuer feeder (admin) post_exchangeSplit à xwinnow0x |
winnow t0x_f10 |
traitement winnow qui publie pour l’échange xsarra pour le téléchargement. Comme deux sources identiques seulement la moitié des messages de notifications sont postés au suivant |
Lire l’AMQP v02 local en tant qu’utilisateur de feeder. Fonction de mise en cache complète (Winnow) post amqp v02 à l’échange local. |
sarra download f20 |
Téléchargez les données Winnowed à partir du répertoire local data mart (TESTDOCROOT= ~/sarra_devdocroot) Ajouter un en-tête au niveau de la couche d’application plus de 255 caractères. |
Lire l’AMQP v02 local (xsarra) Télécharger à l’aide de Python intégré fil d’attente partagé et plusieurs processus 5 instances téléchargent de chaque q télécharge avec accel_wget plugin Troncature d’en-tête AMQP lors de la publication. post amqp v02 à xpublic en tant qu’utilisateur feeder téléchargements HTTP depuis localhst |
subscribe t |
Télécharge en tant que client à partir de localhost au repertoire downloaded_by_sub_t. |
lire amqp du courtier local en tant qu’utilisatuer/client ordinaire. fil d’attente partagé et plusieurs processus 5 instances téléchargent de chaque q |
watch f40 |
regarder downloaded_by_sub_t Publier chaque fichier qui y apparaît Plafond de mémoire réglé bas |
client v03 post du fichier local. (fichier: url) Redémarrage automatique au plafond de la mémoire. |
sender tsource2send |
lire fichier local, envoyer via sftp au répertoire sent_by_tsource2send Publier sur xs_tsource_output |
client consomme des messages de notification v03 Le consommateur lit le fichier local envoyer via sftp. plugin replace_dir Affichage de l’URL sftp. Post V02 (reconversion de V03.) option test post_exchange_suffix. |
subscribe u_sftp_f60 |
Télécharger via sftp à partir de localhost en plaçant les fichiers dans le répertoire downloaded_by_sub_u |
Téléchargement SFTP client. accel_sftp plugin. |
post test2_f61 |
Publier des fichiers dans sent_by_tsource2send avec des URL FTP dans l’échange xs_tsource_poll (Wrapper Script appelle post) |
Affichage explicite de fichiers Publication d’URL ftp. option post_exchange_suffix |
poll f62 |
poller le répertoire sent_by_tsource2send publication d’URL de téléchargement sftp |
option post_exchange_suffix |
subscribe ftp_f70 |
Abonnez-vous aux publications test2_f61 FTP. Télécharger des fichiers depuis localhost au répertoire downloaded_by_sub_u |
Téléchargement d’URL FTP. |
subscribe q_f71 |
s’abonner au sondage, téléchargement sur recd_by_srpoll_test1 |
Confirmation de la qualité du poste de poll |
shovel pclean f90 |
Nettoyez les fichiers pour qu’ils ne s’accumulent pas Simule les échecs pour forcer des nouvelles tentatives |
fonction shovel. Logique de nouvelle tentative. |
shovel pclean f91 |
Nettoyez les fichiers pour qu’ils ne s’accumulent pas |
shovel avec posting v03 Logique de nouvelle tentative. |
shovel pclean f92 |
Nettoyez les fichiers pour qu’ils ne s’accumulent pas |
shovel avec consommation v03 posting v02. Logique de nouvelle tentative. |
Hypothèse: l’environnement de test est un PC Linux, soit un ordinateur portable/de bureau, soit un serveur sur lequel on peut démarrer un navigateur. Si vous travaillez également avec l’implémentation C, il existe également les éléments suivants Flux définis :
Exécution de tests de Flux
Cette section documente ces étapes de manière beaucoup plus détaillée. Avant de pouvoir effectuer les tests sr_insects, certaines conditions préalables doivent être prises en compte. Notez qu’il existe une intégration Github Actions pour au moins la branche principale pour vérifier la fonctionnalité sur une variété de versions de Python. Consulter:
https://github.com/MetPX/sarracenia/actions
Note
Pour les derniers résultats des tests. Notez que les résultats incluent des dizaines de tests et sont peu fiables, il peut généralement falloir quelques tentatives pour que cela fonctionne complètement (3 ou 4 échouent après la tentative initiale, puis réexécutez les échecs, puis peut-être un ou deux resteront, et le troisième passe, et le dernier passe.)
Installer des serveurs sur un poste de travail
Pour préparer un ordinateur à exécuter le test de flux, il faut installer des logiciels et des configurations serveur. Ce même travail est effectué par travis/flow_autoconfig.sh qui est exécuté dans Préparer une machine virtuelle Vanilla mais si vous devez le configurer manuellement, voici le processus.
Installez un courtier localhost minimal et configurez les utilisateurs de test rabbitmq
sudo apt-get install rabbitmq-server
sudo rabbitmq-plugins enable rabbitmq_management
mkdir ~/.config/sarra
cat > ~/.config/sarra/default.conf << EOF
declare env FLOWBROKER=localhost
declare env MQP=amqp
declare env SFTPUSER=${USER}
declare env TESTDOCROOT=${HOME}/sarra_devdocroot
declare env SR_CONFIG_EXAMPLES=${HOME}/git/sarracenia/sarra/examples
EOF
RABBITMQ_PASS=S0M3R4nD0MP4sS
cat > ~/.config/sarra/credentials.conf << EOF
amqp://bunnymaster:${RABBITMQ_PASS}@localhost/
amqp://tsource:${RABBITMQ_PASS}@localhost/
amqp://tsub:${RABBITMQ_PASS}@localhost/
amqp://tfeed:${RABBITMQ_PASS}@localhost/
amqp://anonymous:${RABBITMQ_PASS}@localhost/
amqps://anonymous:anonymous@hpfx.collab.science.gc.ca
amqps://anonymous:anonymous@hpfx1.collab.science.gc.ca
amqps://anonymous:anonymous@hpfx2.collab.science.gc.ca
amqps://anonymous:anonymous@dd.weather.gc.ca
amqps://anonymous:anonymous@dd1.weather.gc.ca
amqps://anonymous:anonymous@dd2.weather.gc.ca
ftp://anonymous:anonymous@localhost:2121/
EOF
cat > ~/.config/sarra/admin.conf << EOF
cluster localhost
admin amqp://bunnymaster@localhost/
feeder amqp://tfeed@localhost/
declare source tsource
declare subscriber tsub
declare subscriber anonymous
EOF
sudo rabbitmqctl delete_user guest
sudo rabbitmqctl add_user bunnymaster ${RABBITMQ_PASS}
sudo rabbitmqctl set_permissions bunnymaster ".*" ".*" ".*"
sudo rabbitmqctl set_user_tags bunnymaster administrator
sudo systemctl restart rabbitmq-server
cd /usr/local/bin
sudo mv rabbitmqadmin rabbitmqadmin.1
sudo wget http://localhost:15672/cli/rabbitmqadmin
sudo chmod 755 rabbitmqadmin
sr3 --users declare
Note
Veuillez utiliser d’autres mots de passe dans les informations d’identification pour votre configuration, juste au cas où. Les mots de passe ne doivent pas être hard-codés dans la suite d’autotests. Les utilisateurs bunnymaster, tsource, tsub et tfeed doivent être utilisés pour exécuter des tests.
L’idée ici est d’utiliser tsource, tsub et tfeed comme comptes de courtier pour tous les auto-test des opérations et stocker les informations d’identification dans le fichier credentials.conf normal. Aucun mot de passe ou fichier clé ne doit être stocké dans l’arborescence source, dans le cadre d’une suite auto-test.
Configurer l’environnement de test de flux
Une fois l’environnement serveur établi, les tests de flux utilisent des transferts sftp vers localhost.
Il est également nécessaire que l’accès ssh sans mot de passe soit configuré sur l’hôte de test pour l’utilisateur de système qui exécutera le test de flux. Cela peut être fait en créant une paire de clés ssh privée/publique pour l’utilisateur (s’il n’y en a pas déjà) et en copiant la clé publique dans le fichier authorized_keys dans le même répertoire que les clés (~/.ssh). Pour les commandes associées, reportez-vous à la section http://www.linuxproblem.org/art_9.html
Notez que sur les systèmes où les anciennes versions de Paramiko (< 2.7.2) sont installées,
et où la paire de clés ssh a été générée avec OpenSSH >= 6.5, tester manuellement la commande
ci-dessous fonctionnera, mais Paramiko ne pourra pas se connecter. C’est probablement le cas s
i le fichier ~/.ssh/id_rsa contient BEGIN OPENSSH PRIVATE KEY. Pour contourner ce problème,
convertissez le format de la clé privée en utilisant ssh-keygen -p -m PEM -f ~/.ssh/id_rsa.
Pour confirmer que ce ssh sans mot de passe vers localhost fonctionne
ssh localhost ls
Cela devrait s’exécuter et se terminer. S’il vous demande un mot de passe, les tests de flux ne fonctionneront pas.
Vérifiez que le courtier focntionne:
systemctl status rabbitmq-server
Une partie du test de flux exécute un serveur sftp et utilise des fonctions client sftp. Besoin du package suivant pour cela:
sudo apt-get install python3-pyftpdlib python3-paramiko
Le script d’installation démarre un serveur Web trivial, un serveur ftp et un démon que sr3_post appelle. Il teste également les composants C, qui doivent également avoir déjà été installés. et définit certains clients de test fixes qui seront utilisés lors des auto-tests
cd
git clone https://github.com/MetPX/sr_insects
cd sr_insects
cd static_flow
. ./flow_setup.sh
blacklab% ./flow_setup.sh
cleaning logs, just in case
rm: cannot remove '/home/peter/.cache/sarra/log/*': No such file or directory
Adding flow test configurations...
2018-02-10 14:22:58,944 [INFO] copying /usr/lib/python3/dist-packages/sarra/examples/cpump/cno_trouble_f00.inc to /home/peter/.config/sarra/cpump/cno_trouble_f00.inc.
2018-02-10 09:22:59,204 [INFO] copying /home/peter/src/sarracenia/sarra/examples/shovel/no_trouble_f00.inc to /home/peter/.config/sarra/shovel/no_trouble_f00.inc
2018-02-10 14:22:59,206 [INFO] copying /usr/lib/python3/dist-packages/sarra/examples/cpost/veille_f34.conf to /home/peter/.config/sarra/cpost/veille_f34.conf.
2018-02-10 14:22:59,207 [INFO] copying /usr/lib/python3/dist-packages/sarra/examples/cpump/pelle_dd1_f04.conf to /home/peter/.config/sarra/cpump/pelle_dd1_f04.conf.
2018-02-10 14:22:59,208 [INFO] copying /usr/lib/python3/dist-packages/sarra/examples/cpump/pelle_dd2_f05.conf to /home/peter/.config/sarra/cpump/pelle_dd2_f05.conf.
2018-02-10 14:22:59,208 [INFO] copying /usr/lib/python3/dist-packages/sarra/examples/cpump/xvan_f14.conf to /home/peter/.config/sarra/cpump/xvan_f14.conf.
2018-02-10 14:22:59,209 [INFO] copying /usr/lib/python3/dist-packages/sarra/examples/cpump/xvan_f15.conf to /home/peter/.config/sarra/cpump/xvan_f15.conf.
2018-02-10 09:22:59,483 [INFO] copying /home/peter/src/sarracenia/sarra/examples/poll/f62.conf to /home/peter/.config/sarra/poll/f62.conf
2018-02-10 09:22:59,756 [INFO] copying /home/peter/src/sarracenia/sarra/examples/post/shim_f63.conf to /home/peter/.config/sarra/post/shim_f63.conf
2018-02-10 09:23:00,030 [INFO] copying /home/peter/src/sarracenia/sarra/examples/post/test2_f61.conf to /home/peter/.config/sarra/post/test2_f61.conf
2018-02-10 09:23:00,299 [INFO] copying /home/peter/src/sarracenia/sarra/examples/report/tsarra_f20.conf to /home/peter/.config/sarra/report/tsarra_f20.conf
2018-02-10 09:23:00,561 [INFO] copying /home/peter/src/sarracenia/sarra/examples/report/twinnow00_f10.conf to /home/peter/.config/sarra/report/twinnow00_f10.conf
2018-02-10 09:23:00,824 [INFO] copying /home/peter/src/sarracenia/sarra/examples/report/twinnow01_f10.conf to /home/peter/.config/sarra/report/twinnow01_f10.conf
2018-02-10 09:23:01,086 [INFO] copying /home/peter/src/sarracenia/sarra/examples/sarra/download_f20.conf to /home/peter/.config/sarra/sarra/download_f20.conf
2018-02-10 09:23:01,350 [INFO] copying /home/peter/src/sarracenia/sarra/examples/sender/tsource2send_f50.conf to /home/peter/.config/sarra/sender/tsource2send_f50.conf
2018-02-10 09:23:01,615 [INFO] copying /home/peter/src/sarracenia/sarra/examples/shovel/t_dd1_f00.conf to /home/peter/.config/sarra/shovel/t_dd1_f00.conf
2018-02-10 09:23:01,877 [INFO] copying /home/peter/src/sarracenia/sarra/examples/shovel/t_dd2_f00.conf to /home/peter/.config/sarra/shovel/t_dd2_f00.conf
2018-02-10 09:23:02,137 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/cclean_f91.conf to /home/peter/.config/sarra/subscribe/cclean_f91.conf
2018-02-10 09:23:02,400 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/cdnld_f21.conf to /home/peter/.config/sarra/subscribe/cdnld_f21.conf
2018-02-10 09:23:02,658 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/cfile_f44.conf to /home/peter/.config/sarra/subscribe/cfile_f44.conf
2018-02-10 09:23:02,921 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/clean_f90.conf to /home/peter/.config/sarra/subscribe/clean_f90.conf
2018-02-10 09:23:03,185 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/cp_f61.conf to /home/peter/.config/sarra/subscribe/cp_f61.conf
2018-02-10 09:23:03,455 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/ftp_f70.conf to /home/peter/.config/sarra/subscribe/ftp_f70.conf
2018-02-10 09:23:03,715 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/q_f71.conf to /home/peter/.config/sarra/subscribe/q_f71.conf
2018-02-10 09:23:03,978 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/t_f30.conf to /home/peter/.config/sarra/subscribe/t_f30.conf
2018-02-10 09:23:04,237 [INFO] copying /home/peter/src/sarracenia/sarra/examples/subscribe/u_sftp_f60.conf to /home/peter/.config/sarra/subscribe/u_sftp_f60.conf
2018-02-10 09:23:04,504 [INFO] copying /home/peter/src/sarracenia/sarra/examples/watch/f40.conf to /home/peter/.config/sarra/watch/f40.conf
2018-02-10 09:23:04,764 [INFO] copying /home/peter/src/sarracenia/sarra/examples/winnow/t00_f10.conf to /home/peter/.config/sarra/winnow/t00_f10.conf
2018-02-10 09:23:05,027 [INFO] copying /home/peter/src/sarracenia/sarra/examples/winnow/t01_f10.conf to /home/peter/.config/sarra/winnow/t01_f10.conf
Initializing with sr_audit... takes a minute or two
OK, as expected 18 queues existing after 1st audit
OK, as expected 31 exchanges for flow test created.
Starting trivial http server on: /home/peter/sarra_devdocroot, saving pid in .httpserverpid
Starting trivial ftp server on: /home/peter/sarra_devdocroot, saving pid in .ftpserverpid
running self test ... takes a minute or two
sr_util.py TEST PASSED
sr_credentials.py TEST PASSED
sr_config.py TEST PASSED
sr_cache.py TEST PASSED
sr_retry.py TEST PASSED
sr_consumer.py TEST PASSED
sr_http.py TEST PASSED
sftp testing start...
sftp testing config read...
sftp testing fake message built ...
sftp sr_ftp instantiated ...
sftp sr_ftp connected ...
sftp sr_ftp mkdir ...
test 01: directory creation succeeded
test 02: file upload succeeded
test 03: file rename succeeded
test 04: getting a part succeeded
test 05: download succeeded
test 06: onfly_checksum succeeded
Sent: bbb into tztz/ddd 0-5
test 07: download succeeded
test 08: delete succeeded
Sent: bbb into tztz/ddd 0-5
Sent: bbb into tztz/ddd 0-5
Sent: bbb into tztz/ddd 0-5
Sent: bbb into tztz/ddd 0-5
Sent: bbb into tztz/ddd 0-5
/home/peter
/home/peter
test 09: bad part succeeded
sr_sftp.py TEST PASSED
sr_instances.py TEST PASSED
OK, as expected 9 tests passed
Starting flow_post on: /home/peter/sarra_devdocroot, saving pid in .flowpostpid
Starting up all components (sr start)...
done.
OK: sr3 start was successful
Overall PASSED 4/4 checks passed!
blacklab%
Lorsqu’il exécute le programme d’installation, il exécute également tous les unit_tests existants. Ne passez aux tests flow_check que si tous les tests de flow_setup.sh réussissent.
Exécuter un test de Flux
Le script flow_check.sh lit les fichiers journaux de tous les composants démarrés et compare le nombre de messages de notification, à la recherche d’une correspondance dans les +- 10%. Il faut quelques minutes pour que la configuration s’exécute avant qu’il y ait suffisamment de données pour effectuer les mesures correctes
./flow_limit.sh
sample output:
initial sample building sample size 8 need at least 1000
sample now 1021
Sufficient!
stopping shovels and waiting...
2017-10-28 00:37:02,422 [INFO] sr_shovel t_dd1_f00 0001 stopping
2017-10-28 04:37:02,435 [INFO] 2017-10-28 04:37:02,435 [INFO] info: instances option not implemented, ignored.
info: instances option not implemented, ignored.
2017-10-28 04:37:02,435 [INFO] 2017-10-28 04:37:02,435 [INFO] info: report option not implemented, ignored.
info: report option not implemented, ignored.
2017-10-28 00:37:02,436 [INFO] sr_shovel t_dd2_f00 0001 stopping
running instance for config pelle_dd1_f04 (pid 15872) stopped.
running instance for config pelle_dd2_f05 (pid 15847) stopped.
maximum of the shovels is: 1022
Ensuite, vérifiez avec flow_check.sh:
TYPE OF ERRORS IN LOG :
1 /home/peter/.cache/sarra/log/sr_cpump_xvan_f14_001.log [ERROR] binding failed: server channel error 404h, message: NOT_FOUND - no exchange 'xcvan00' in vhost '/'
1 /home/peter/.cache/sarra/log/sr_cpump_xvan_f15_001.log [ERROR] binding failed: server channel error 404h, message: NOT_FOUND - no exchange 'xcvan01' in vhost '/'
test 1 success: shovels t_dd1_f00 ( 1022 ) and t_dd2_f00 ( 1022 ) should have about the same number of items read
test 2 success: sarra tsarra (1022) should be reading about half as many items as (both) winnows (2240)
test 3 success: tsarra (1022) and sub t_f30 (1022) should have about the same number of items
test 4 success: max shovel (1022) and subscriber t_f30 (1022) should have about the same number of items
test 5 success: count of truncated headers (1022) and subscribed messages (1022) should have about the same number of items
test 6 success: count of downloads by subscribe t_f30 (1022) and messages received (1022) should be about the same
test 7 success: downloads by subscribe t_f30 (1022) and files posted by sr3_watch (1022) should be about the same
test 8 success: posted by watch(1022) and sent by sr_sender (1022) should be about the same
test 9 success: 1022 of 1022: files sent with identical content to those downloaded by subscribe
test 10 success: 1022 of 1022: poll test1_f62 and subscribe q_f71 run together. Should have equal results.
test 11 success: post test2_f61 1022 and subscribe r_ftp_f70 1021 run together. Should be about the same.
test 12 success: cpump both pelles (c shovel) should receive about the same number of messages (3665) (3662)
test 13 success: cdnld_f21 subscribe downloaded (1022) the same number of files that was published by both van_14 and van_15 (1022)
test 14 success: veille_f34 should post the same number of files (1022) that subscribe cdnld_f21 downloaded (1022)
test 15 success: veille_f34 should post the same number of files (1022) that subscribe cfile_f44 downloaded (1022)
test 16 success: Overall 15 of 15 passed!
blacklab%
Si le flow_check.sh est adopté, alors on a une confiance raisonnable dans la fonctionnalité globale de Python, mais la couverture du test n’est pas exhaustive. C’est la porte la plus basse pour s’engager à des modifications apportées à votre code Python dans la branche principale. Il s’agit d’un échantillonnage plus qualitatif des cas d’utilisation courants plutôt qu’un examen approfondi de toutes les fonctionnalités. Bien que ce ne soit pas le cas approfondie, il est bon de savoir que les flux fonctionnent.
Notez que l’abonné fclean examine les fichiers et les conserve suffisamment longtemps pour qu’ils puissent parcourir tous les autres tests. Il le fait en attendant un délai raisonnable (45 secondes, la dernière fois vérifiée), puis il compare le fichier qui a été posté par sr3_watch aux fichiers créés en téléchargeant à partir de celui-ci. Au fur et à mesure que le dénombrement sample now progresse, il imprime “OK” si les fichiers téléchargés sont identiques à ceux postés par sr_watch. L’ajout de fclean et cfclean correspondant pour les cflow_test sont cassés. La configuration par défaut qui utilise fclean et cfclean garantit que seulement quelques minutes d’espace disque sont utilisées à un moment donné et permettent des tests beaucoup plus longs.
Par défaut, le flow_test n’est que de 1000 fichiers, mais on peut lui demander de fonctionner plus longtemps, comme ceci:
./flow_limit.sh 50000
Pour accumuler cinquante mille fichiers avant de terminer le test. Cela permet de tester les performances à long terme, en particulier l’utilisation de la mémoire au fil du temps et des fonctions d’entretien du traitement on_heartbeat.
Flow Cleanup
Une fois le test terminé, exécutez le script ./flow_cleanup.sh, qui tuera les serveurs et les démons en cours d’exécution et supprimera tous les fichiers de configuration installés pour le test de flux, toutes les files d’attente, les échanges et les journaux. Cela doit également être fait entre chaque exécution du test de flux:
blacklab% ./flow_cleanup.sh
Stopping sr...
Cleanup sr...
Cleanup trivial http server...
web server stopped.
if other web servers with lost pid kill them
Cleanup trivial ftp server...
ftp server stopped.
if other ftp servers with lost pid kill them
Cleanup flow poster...
flow poster stopped.
if other flow_post.sh with lost pid kill them
Deleting queues:
Deleting exchanges...
Removing flow configs...
2018-02-10 14:17:34,150 [INFO] info: instances option not implemented, ignored.
2018-02-10 14:17:34,150 [INFO] info: report option not implemented, ignored.
2018-02-10 14:17:34,353 [INFO] info: instances option not implemented, ignored.
2018-02-10 14:17:34,353 [INFO] info: report option not implemented, ignored.
2018-02-10 09:17:34,837 [INFO] sr_poll f62 cleanup
2018-02-10 09:17:34,845 [INFO] deleting exchange xs_tsource_poll (tsource@localhost)
2018-02-10 09:17:35,115 [INFO] sr3_post shim_f63 cleanup
2018-02-10 09:17:35,122 [INFO] deleting exchange xs_tsource_shim (tsource@localhost)
2018-02-10 09:17:35,394 [INFO] sr3_post test2_f61 cleanup
2018-02-10 09:17:35,402 [INFO] deleting exchange xs_tsource_post (tsource@localhost)
2018-02-10 09:17:35,659 [INFO] sr_report tsarra_f20 cleanup
2018-02-10 09:17:35,659 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:35,661 [INFO] deleting queue q_tfeed.sr_report.tsarra_f20.89336558.04455188 (tfeed@localhost)
2018-02-10 09:17:35,920 [INFO] sr_report twinnow00_f10 cleanup
2018-02-10 09:17:35,920 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:35,922 [INFO] deleting queue q_tfeed.sr_report.twinnow00_f10.35552245.50856337 (tfeed@localhost)
2018-02-10 09:17:36,179 [INFO] sr_report twinnow01_f10 cleanup
2018-02-10 09:17:36,180 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:36,182 [INFO] deleting queue q_tfeed.sr_report.twinnow01_f10.48262886.11567358 (tfeed@localhost)
2018-02-10 09:17:36,445 [WARNING] option url deprecated please use post_base_url
2018-02-10 09:17:36,446 [WARNING] use post_base_dir instead of document_root
2018-02-10 09:17:36,446 [INFO] sr_sarra download_f20 cleanup
2018-02-10 09:17:36,446 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:36,448 [INFO] deleting queue q_tfeed.sr_sarra.download_f20 (tfeed@localhost)
2018-02-10 09:17:36,449 [INFO] exchange xpublic remains
2018-02-10 09:17:36,703 [INFO] sr_sender tsource2send_f50 cleanup
2018-02-10 09:17:36,703 [INFO] AMQP broker(localhost) user(tsource) vhost(/)
2018-02-10 09:17:36,705 [INFO] deleting queue q_tsource.sr_sender.tsource2send_f50 (tsource@localhost)
2018-02-10 09:17:36,711 [INFO] deleting exchange xs_tsource_output (tsource@localhost)
2018-02-10 09:17:36,969 [INFO] sr_shovel t_dd1_f00 cleanup
2018-02-10 09:17:36,969 [INFO] AMQP broker(dd.weather.gc.ca) user(anonymous) vhost(/)
2018-02-10 09:17:37,072 [INFO] deleting queue q_anonymous.sr_shovel.t_dd1_f00 (anonymous@dd.weather.gc.ca)
2018-02-10 09:17:37,095 [INFO] exchange xwinnow00 remains
2018-02-10 09:17:37,095 [INFO] exchange xwinnow01 remains
2018-02-10 09:17:37,389 [INFO] sr_shovel t_dd2_f00 cleanup
2018-02-10 09:17:37,389 [INFO] AMQP broker(dd.weather.gc.ca) user(anonymous) vhost(/)
2018-02-10 09:17:37,498 [INFO] deleting queue q_anonymous.sr_shovel.t_dd2_f00 (anonymous@dd.weather.gc.ca)
2018-02-10 09:17:37,522 [INFO] exchange xwinnow00 remains
2018-02-10 09:17:37,523 [INFO] exchange xwinnow01 remains
2018-02-10 09:17:37,804 [INFO] sr_subscribe cclean_f91 cleanup
2018-02-10 09:17:37,804 [INFO] AMQP broker(localhost) user(tsub) vhost(/)
2018-02-10 09:17:37,806 [INFO] deleting queue q_tsub.sr_subscribe.cclean_f91.39328538.44917465 (tsub@localhost)
2018-02-10 09:17:38,062 [INFO] sr_subscribe cdnld_f21 cleanup
2018-02-10 09:17:38,062 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:38,064 [INFO] deleting queue q_tfeed.sr_subscribe.cdnld_f21.11963392.61638098 (tfeed@localhost)
2018-02-10 09:17:38,324 [WARNING] use post_base_dir instead of document_root
2018-02-10 09:17:38,324 [INFO] sr_subscribe cfile_f44 cleanup
2018-02-10 09:17:38,324 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:38,326 [INFO] deleting queue q_tfeed.sr_subscribe.cfile_f44.56469334.87337271 (tfeed@localhost)
2018-02-10 09:17:38,583 [INFO] sr_subscribe clean_f90 cleanup
2018-02-10 09:17:38,583 [INFO] AMQP broker(localhost) user(tsub) vhost(/)
2018-02-10 09:17:38,585 [INFO] deleting queue q_tsub.sr_subscribe.clean_f90.45979835.20516428 (tsub@localhost)
2018-02-10 09:17:38,854 [WARNING] extended option download_cp_command = ['cp --preserve=timestamps'] (unknown or not declared)
2018-02-10 09:17:38,855 [INFO] sr_subscribe cp_f61 cleanup
2018-02-10 09:17:38,855 [INFO] AMQP broker(localhost) user(tsource) vhost(/)
2018-02-10 09:17:38,857 [INFO] deleting queue q_tsource.sr_subscribe.cp_f61.61218922.69758215 (tsource@localhost)
2018-02-10 09:17:39,121 [INFO] sr_subscribe ftp_f70 cleanup
2018-02-10 09:17:39,121 [INFO] AMQP broker(localhost) user(tsource) vhost(/)
2018-02-10 09:17:39,123 [INFO] deleting queue q_tsource.sr_subscribe.ftp_f70.47997098.27633529 (tsource@localhost)
2018-02-10 09:17:39,386 [INFO] sr_subscribe q_f71 cleanup
2018-02-10 09:17:39,386 [INFO] AMQP broker(localhost) user(tsource) vhost(/)
2018-02-10 09:17:39,389 [INFO] deleting queue q_tsource.sr_subscribe.q_f71.84316550.21567557 (tsource@localhost)
2018-02-10 09:17:39,658 [INFO] sr_subscribe t_f30 cleanup
2018-02-10 09:17:39,658 [INFO] AMQP broker(localhost) user(tsub) vhost(/)
2018-02-10 09:17:39,660 [INFO] deleting queue q_tsub.sr_subscribe.t_f30.26453890.50752396 (tsub@localhost)
2018-02-10 09:17:39,924 [INFO] sr_subscribe u_sftp_f60 cleanup
2018-02-10 09:17:39,924 [INFO] AMQP broker(localhost) user(tsource) vhost(/)
2018-02-10 09:17:39,927 [INFO] deleting queue q_tsource.sr_subscribe.u_sftp_f60.81353341.03950190 (tsource@localhost)
2018-02-10 09:17:40,196 [WARNING] option url deprecated please use post_base_url
2018-02-10 09:17:40,196 [WARNING] use post_broker to set broker
2018-02-10 09:17:40,197 [INFO] sr3_watch f40 cleanup
2018-02-10 09:17:40,207 [INFO] deleting exchange xs_tsource (tsource@localhost)
2018-02-10 09:17:40,471 [INFO] sr_winnow t00_f10 cleanup
2018-02-10 09:17:40,471 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:40,474 [INFO] deleting queue q_tfeed.sr_winnow.t00_f10 (tfeed@localhost)
2018-02-10 09:17:40,480 [INFO] deleting exchange xsarra (tfeed@localhost)
2018-02-10 09:17:40,741 [INFO] sr_winnow t01_f10 cleanup
2018-02-10 09:17:40,741 [INFO] AMQP broker(localhost) user(tfeed) vhost(/)
2018-02-10 09:17:40,743 [INFO] deleting queue q_tfeed.sr_winnow.t01_f10 (tfeed@localhost)
2018-02-10 09:17:40,750 [INFO] deleting exchange xsarra (tfeed@localhost)
2018-02-10 14:17:40,753 [ERROR] config cno_trouble_f00 not found.
Removing flow config logs...
rm: cannot remove '/home/peter/.cache/sarra/log/sr_audit_f00.log': No such file or directory
Removing document root ( /home/peter/sarra_devdocroot )...
Done!
Après la flow_cleanup.sh, pour vérifier qu’un test est terminé, utiliser:
sr3 status
ce qui devrait montrer qu’il n’y a pas de configurations actives.
Si le test static_flow fonctionne, réexécutez les autres tests : flakey_broker, transform_flow, et dynamic_flow.
Longueur du test Dynamic Flow
Alors que la plupart des tests ont une durée fixe, le test de flux dynamique interroge une serveur distant et peut fonctionner pour n’importe quelle longueur souhaitée. La longueur du flow_test dynamique par défaut est de 1000 fichiers circulant dans les cas de test. En cas de développement rapide, on peut fournir un argument pour raccourcir cela:
./flow_limit.sh 200
Vers la fin d’un cycle de développement, des flow_tests plus longs sont conseillées:
./flow_limit.sh 20000
pour identifier plus de problèmes. Exemple d’exécution à 100 000 entrées
blacklab% ./flow_limit.sh 100000
initial sample building sample size 155 need at least 100000
sample now 100003 content_checks:GOOD missed_dispositions:0s:0
Sufficient!
stopping shovels and waiting...
2018-02-10 13:15:08,964 [INFO] 2018-02-10 13:15:08,964 [INFO] info: instances option not implemented, ignored.
info: instances option not implemented, ignored.
2018-02-10 13:15:08,964 [INFO] info: report option not implemented, ignored.
2018-02-10 13:15:08,964 [INFO] info: report option not implemented, ignored.
running instance for config pelle_dd2_f05 (pid 20031) stopped.
running instance for config pelle_dd1_f04 (pid 20043) stopped.
Traceback (most recent call last):ng...
File "/usr/bin/rabbitmqadmin", line 1012, in <module>
main()
File "/usr/bin/rabbitmqadmin", line 413, in main
method()
File "/usr/bin/rabbitmqadmin", line 593, in invoke_list
format_list(self.get(uri), cols, obj_info, self.options)
File "/usr/bin/rabbitmqadmin", line 710, in format_list
formatter_instance.display(json_list)
File "/usr/bin/rabbitmqadmin", line 721, in display
(columns, table) = self.list_to_table(json.loads(json_list), depth)
File "/usr/bin/rabbitmqadmin", line 775, in list_to_table
add('', 1, item, add_to_row)
File "/usr/bin/rabbitmqadmin", line 742, in add
add(column, depth + 1, subitem, fun)
File "/usr/bin/rabbitmqadmin", line 742, in add
add(column, depth + 1, subitem, fun)
File "/usr/bin/rabbitmqadmin", line 754, in add
fun(column, subitem)
File "/usr/bin/rabbitmqadmin", line 761, in add_to_row
row[column_ix[col]] = maybe_utf8(val)
File "/usr/bin/rabbitmqadmin", line 431, in maybe_utf8
return s.encode('utf-8')
AttributeError: 'float' object has no attribute 'encode'
maximum of the shovels is: 100008
While it is runnig one can run flow_check.sh at any time:
NB retries for sr_subscribe t_f30 0
NB retries for sr_sender 18
1 /home/peter/.cache/sarra/log/sr_cpost_veille_f34_0001.log [ERROR] sr_cpost rename: /home/peter/sarra_devdocroot/cfr/observations/xml/AB/today/today_ab_20180210_e.xml cannot stat.
1 /home/peter/.cache/sarra/log/sr_cpump_xvan_f14_0001.log [ERROR] binding failed: server channel error 404h, message: NOT_FOUND - no exchange 'xcvan00' in vhost '/'
1 /home/peter/.cache/sarra/log/sr_cpump_xvan_f15_0001.log [ERROR] binding failed: server channel error 404h, message: NOT_FOUND - no exchange 'xcvan01' in vhost '/'
1 /home/peter/.cache/sarra/log/sr_sarra_download_f20_0002.log [ERROR] Download failed http://dd2.weather.gc.ca//bulletins/alphanumeric/20180210/CA/CWAO/09/CACN00_CWAO_100857__WDK_10905
1 /home/peter/.cache/sarra/log/sr_sarra_download_f20_0002.log [ERROR] Failed to reach server. Reason: [Errno 110] Connection timed out
1 /home/peter/.cache/sarra/log/sr_sarra_download_f20_0002.log [ERROR] Download failed http://dd2.weather.gc.ca//bulletins/alphanumeric/20180210/CA/CWAO/09/CACN00_CWAO_100857__WDK_10905. Type: <class 'urllib.error.URLError'>, Value: <urlopen error [Errno 110] Connection timed out>
1 /home/peter/.cache/sarra/log/sr_sarra_download_f20_0004.log [ERROR] Download failed http://dd2.weather.gc.ca//bulletins/alphanumeric/20180210/SA/CYMM/09/SACN61_CYMM_100900___53321
1 /home/peter/.cache/sarra/log/sr_sarra_download_f20_0004.log [ERROR] Failed to reach server. Reason: [Errno 110] Connection timed out
1 /home/peter/.cache/sarra/log/sr_sarra_download_f20_0004.log [ERROR] Download failed http://dd2.weather.gc.ca//bulletins/alphanumeric/20180210/SA/CYMM/09/SACN61_CYMM_100900___53321. Type: <class 'urllib.error.URLError'>, Value: <urlopen error [Errno 110] Connection timed out>
1 /home/peter/.cache/sarra/log/sr_sarra_download_f20_0004.log [ERROR] Download failed http://dd2.weather.gc.ca//bulletins/alphanumeric/20180210/CS/CWEG/12/CSCN03_CWEG_101200___12074
more than 10 TYPES OF ERRORS found... for the rest, have a look at /home/peter/src/sarracenia/test/flow_check_errors_logged.txt for details
test 1 success: shovels t_dd1_f00 (100008) and t_dd2_f00 (100008) should have about the same number of items read
test 2 success: sarra tsarra (100008) should be reading about half as many items as (both) winnows (200016)
test 3 success: tsarra (100008) and sub t_f30 (99953) should have about the same number of items
test 4 success: max shovel (100008) and subscriber t_f30 (99953) should have about the same number of items
test 5 success: count of truncated headers (100008) and subscribed messages (100008) should have about the same number of items
test 6 success: count of downloads by subscribe t_f30 (99953) and messages received (100008) should be about the same
test 7 success: same downloads by subscribe t_f30 (199906) and files posted (add+remove) by sr3_watch (199620) should be about the same
test 8 success: posted by watch(199620) and subscribed cp_f60 (99966) should be about half as many
test 9 success: posted by watch(199620) and sent by sr_sender (199549) should be about the same
test 10 success: 0 messages received that we don't know what happenned.
test 11 success: sarra tsarra (100008) and good audit 99754 should be the same.
test 12 success: poll test1_f62 94865 and subscribe q_f71 99935 run together. Should have equal results.
test 13 success: post test2_f61 99731 and subscribe r_ftp_f70 99939 run together. Should be about the same.
test 14 success: posts test2_f61 99731 and shim_f63 110795 Should be the same.
test 15 success: cpump both pelles (c shovel) should receive about the same number of messages (160737) (160735)
test 16 success: cdnld_f21 subscribe downloaded (50113) the same number of files that was published by both van_14 and van_15 (50221)
test 17 success: veille_f34 should post twice as many files (100205) as subscribe cdnld_f21 downloaded (50113)
test 18 success: veille_f34 should post twice as many files (100205) as subscribe cfile_f44 downloaded (49985)
test 19 success: Overall 18 of 18 passed (sample size: 100008) !
blacklab%
Ce test a été lancé en fin de journée, car il prend plusieurs heures, et les résultats examinés le lendemain matin.
Échantillon à volume élevé
Essayer le test de flux avec un volume plus élevé de messages de notification (c’est-à-dire 100 000) est un pas de plus vers l’objectif d’avoir un test de flux exécuté en continu. Ceci est motivé par nos objectifs de test.
Limitation
Ubuntu a une limitation qui surpasse les montres inotify et que nous avons rencontrée dans #204 . Nous pouvons surmonter cela en définissant la variable sysctl associée. Tout d’abord, vérifiez quelle est la limite de votre système:
$ sysctl fs.inotify.max_user_watches
fs.inotify.max_user_watches = 8196
Si la limite est trop basse (c.-à-d. 8196), changez-la à un niveau plus approprié pour l’essai de débit:
$ sudo sysctl fs.inotify.max_user_watches=524288
Pour rendre cette modification permanente, ajoutez cette ligne à /etc/sysctl.conf:
fs.inotify.max_user_watches=524288
Puis excuter sysctl -p Et le système devrait maintenant prendre en charge un volume élevé d’événements iNotify.
Flow Test Coincé
Parfois, les tests de flux (en particulier pour les grands nombres) sont bloqués en raison de problèmes avec le flux de données (où plusieurs fichiers obtiennent le même nom) et donc les versions antérieures suppriment les versions ultérieures et les nouvelles tentatives échouent toujours. Finalement, nous réussirons à nettoyer le flux dd.weather.gc.ca, mais pour l’instant, il arrive parfois qu’un flow_check reste bloqué à “Retrying”. Le test a exécuté tous les messages de notification requis et est à une phase de vidange des tentatives, mais continue de réessayer pour toujours avec un nombre variable d’éléments qui ne tombe jamais à zéro.
Pour récupérer de cet état sans rejeter les résultats d’un test long, procédez comme suit:
^C to interrupt the flow_check.sh 100000
blacklab% sr3 stop
blacklab% cd ~/.cache/sarra
blacklab% ls */*/*retry*
shovel/pclean_f90/sr_shovel_pclean_f90_0001.retry shovel/pclean_f92/sr_shovel_pclean_f92_0001.retry subscribe/t_f30/sr_subscribe_t_f30_0002.retry.new
shovel/pclean_f91/sr_shovel_pclean_f91_0001.retry shovel/pclean_f92/sr_shovel_pclean_f92_0001.retry.state
shovel/pclean_f91/sr_shovel_pclean_f91_0001.retry.state subscribe/q_f71/sr_subscribe_q_f71_0004.retry.new
blacklab% rm */*/*retry*
blacklab% sr3 start
blacklab%
blacklab% ./flow_check.sh 100000
Sufficient!
stopping shovels and waiting...
2018-04-07 10:50:16,167 [INFO] sr_shovel t_dd2_f00 0001 stopped
2018-04-07 10:50:16,177 [INFO] sr_shovel t_dd1_f00 0001 stopped
2018-04-07 14:50:16,235 [INFO] info: instances option not implemented, ignored.
2018-04-07 14:50:16,235 [INFO] info: report option not
implemented, ignored.
2018-04-07 14:50:16,235 [INFO] info: instances option not implemented, ignored.
2018-04-07 14:50:16,235 [INFO] info: report option not
implemented, ignored.
running instance for config pelle_dd1_f04 (pid 12435) stopped.
running instance for config pelle_dd2_f05 (pid 12428) stopped.
maximum of the shovels is: 100075
blacklab% ./flow_check.sh
| dd.weather routing |
test 1 success: sr_shovel (100075) t_dd1 should have the same number
of items as t_dd2 (100068)
test 2 success: sr_winnow (200143) should have the sum of the number
of items of shovels (200143)
test 3 success: sr_sarra (98075) should have the same number of items
as winnows'post (100077)
test 4 success: sr_subscribe (98068) should have the same number of
items as sarra (98075)
| watch routing |
test 5 success: sr3_watch (397354) should be 4 times subscribe t_f30 (98068)
test 6 success: sr_sender (392737) should have about the same number
of items as sr3_watch (397354)
test 7 success: sr_subscribe u_sftp_f60 (361172) should have the same
number of items as sr_sender (392737)
test 8 success: sr_subscribe cp_f61 (361172) should have the same
number of items as sr_sender (392737)
| poll routing |
test 9 success: sr_poll test1_f62 (195408) should have half the same
number of items of sr_sender(196368)
test 10 success: sr_subscribe q_f71 (195406) should have about the
same number of items as sr_poll test1_f62(195408)
| flow_post routing |
test 11 success: sr3_post test2_f61 (193541) should have half the same
number of items of sr_sender(196368)
test 12 success: sr_subscribe ftp_f70 (193541) should have about the
same number of items as sr3_post test2_f61(193541)
test 13 success: sr3_post test2_f61 (193541) should have about the same
number of items as shim_f63 195055
| py infos routing |
test 14 success: sr_shovel pclean_f90 (97019) should have the same
number of watched items winnows'post (100077)
test 15 success: sr_shovel pclean_f92 (94537}) should have the same
number of removed items winnows'post (100077)
test 16 success: 0 messages received that we don't know what happenned.
test 17 success: count of truncated headers (98075) and subscribed
messages (98075) should have about the same number of items
| C routing |
test 18 success: cpump both pelles (c shovel) should receive about the
same number of messages (161365) (161365)
test 19 success: cdnld_f21 subscribe downloaded (47950) the same
number of files that was published by both van_14 and van_15 (47950)
test 20 success: veille_f34 should post twice as many files (95846) as
subscribe cdnld_f21 downloaded (47950)
test 21 success: veille_f34 should post twice as many files (95846) as
subscribe cfile_f44 downloaded (47896)
test 22 success: Overall 21 of 21 passed (sample size: 100077) !
NB retries for sr_subscribe t_f30 0
NB retries for sr_sender 36
Donc, dans ce cas, les résultats sont toujours bons en dépit de ne pas être tout à fait capable de résilier. S’il y avait un problème important, le cumul l’indiquerait.
Flow tests avec MQTT
Les tests de flux peuvent être exécutés lorsque certains composants utilisent le protocole MQTT, au lieu d’AMQP.
FIXME: étapes manquantes, plus de clarté requise.
Le courtier MQTT est installé
Les utilisateurs de BunnyMaster Tsource, Tfeed, Tsub sont définis et ont reçu des mots de passe (dépendants du courtier.)
Pour chaque utilisateur : une ligne d’URL mqtt://user:pw@brokerhost est ajoutée à ~/.config/sr3/credentials.conf
modifier la variable MQP dans ~/.config/sr3/default.conf, MQP est utilisée par les tests de flux.
La plupart des composants utiliseront MQTT au lieu d’amqp et peuvent être exécutés normalement.
Commits vers la branche principale
A part les fautes de frappe, les corrections de langue dans la documentation et l’incrémentation de la version, les développeurs ne sont pas censés s’engager sur Main (branche principale). Tous les travaux se produisent sur les branches de développement, et tous les tests doivent réussir avant de considerer d’affecter Main. Une fois le développement de la branche terminé, ou qu’une unité de travaux en cours est jugée utile de fusionner avec la branche principale, on doit résumer les modifications de la branche pour le journal des modifications de Debian, demande sur GitHub.
git checkout issueXXX # v02_issueXXX pour du travaille sur l´ancienne version.
dch # résumer les changement dans changelog.
vi doc/UPGRADING.rst # rarement en cas de changement visible dont l´usager doit prendre connaissance.
vi doc/fr/UPGRADING.rst # bon... ceci est visible aux usagers, donc...
git commit -a
git push
# déclencher un *pull request* chez github.com
Un deuxième développeur examinera la demande d’extraction et le réviseur décidera si la fusion est appropriée. On s’attend à ce que le développeur examine chaque validation, et la comprenne dans une certaine mesure.
Le github Actions examine les pull requests et effectue des tests de flux sur celles-ci. Si les tests réussissent, alors c’est un bon indicateur qualitatif, mais les tests sont un peu fragile pour le moment, donc s’ils échouent, il serait idéal que le réviseur exécute les tests dans leur propre environnement de développement. S’il passe dans l’environnement du développeur local on peut approuver une fusion malgré les plaintes de Github Actions.
Branches Principales
Il y a une longue discussion sur Quelle version est stable La configuration actuelle est qu’il y a quatre branches principales:
La branche principale est la version finale de SR3, fusionnant à partir de development. Utilisé pour créer des packages SR3 dans le référentiel MetPX.
development … La version 3 La branche de travail en cours (WIP) est une prochaine version de Sarracenia en développement. La branche development est utilisée pour créer des packages sr3 pour le Quotidien et les référentiels Pre-Release sur launchpad.net.
Les branches de issue à fusionner avec development, devraient s’appeler v3_issueXXX
v2_dev … La branche d’intégration pour la maintenance v2 utilisée avant la promotion à v2_stable.
v2_stable … Généralement, cette branche obtient du code via des fusions à partir de v2_dev, après que la pré-version a été testée sur autant de systèmes que possible. Utilisé pour construire des paquets sur la version stable: MetPX
les branches issues à fusionner avec stable doivent être appelées issueXXX.
Dépots de pacquets Ubuntu: Launchpad.net
Pour les systèmes d’exploitation Ubuntu, le site launchpad.net est le meilleur moyen de fournir des packages entièrement intégrés (construit par rapport aux niveaux de correctifs actuels de toutes les dépendances (composants logiciels sur lesquels Sarracenia s’appuie) pour fournir toutes les fonctionnalités.)) Idéalement, lors de l’exécution d’un serveur, on devrait utiliser l’un des référentiels, et permettre des correctifs automatisés pour les mettre à niveau selon les besoins.
Référentiels:
Quotidien https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-daily (Vivre sur le fil du rasoir… ) La construction quotidienne automatisée des paquets SR3 se fait à partir de la branche development.
Pré-release https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-pre-release (pour les fonctionnalités les plus récentes.) De la branche development. Les développeurs déclenchent manuellement les builds ici lorsque cela semble approprié (tester du code prêt à être publié.)
Release https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx (pour une stabilité maximale) de la branche v2_stable. Après avoir testé dans des systèmes souscrits à des versions préliminaires, les développeurs fusionnent la branche v2_dev à v2_stable et déclenchent manuellement une génération.
Pour plus de détails, voir Quelle version est stable
Local Python
Utilisation d’une version non packagée :
Note
python3 setup.py build python3 setup.py install
Windows
Installez winpython à partir de github.io version 3.4 ou supérieure. Utilisez ensuite pip pour installer à partir de PyPI.
Conventions
Vous trouverez ci-dessous quelques pratiques de codage destinées à guider les développeurs lorsqu’il contribuent à Sarracenia. Ce ne sont pas des règles strictes, juste des conseils.
Quand signaler
sr_report(7) Les messages de notification doivent être émis pour indiquer la disposition finale des données elles-mêmes, et non des notifications ou des messages de rapport (ne signalez pas les messages de rapport, cela devient une boucle infinie!) Pour le débogage et d’autres informations, le fichier journal local est utilisé. Par exemple, sr_shovel n’émet aucun message sr_report(7), car aucune donnée n’est transférée, seulement des messages.
Àjout d´un Dépendence
La gestion des dépendances est un sujet compliqué, car python a de nombreuses méthodes d’installation différentes dans des environnements disparates, et Sarracenia est multi-plateforme. La pratique standard de python pour les dépendances consiste à faire les nécessaires en les listant dans requirements.txt ou setup.py, et demandez à tous les utilisateurs de les installer. Dans la plupart des applications python, si une dépendance est manquante, elle se bloque simplement avec un message d’échec d’importation de quelques sortes.
Dans Sr3, nous avons constaté qu’il existe de nombreux environnements différents déployés dans lesquels les dépendances peuvent être plus gênantes qu’elles n’en valent la peine, donc chacune des dépendances dans setup.py est également traité dans sarracenia/featuredetection, et le code de détection de fonctionnalité permet à l’application de continuer à travailler, juste sans la fonctionnalité fournie par le module manquant. C’est ce qu’on appelle la dégradation ou mode dégradé. L’idée étant d’aider l’utilisateur à faire le maximum, dans l’environnement dont il dispose, tout en leur disant ce qui manque, et ce qu’il faudrait idéalement ajouter.
pleine discussion (en anglais seulement):
Managing Dependencies (Discussion)
version courte:
En plus de requirements.dev/setup.py, si vous devez ajouter une nouvelle bibliothèque qui ne fait pas partie de piles incluses, généralement fournies par un package os ou pip séparé, alors vous voulez prévoir que sr3 fonctionne toujours dans le cas où le package n’est pas disponible (bien que sans la fonction que vous ajoutez) et pour ajouter un support pour expliquer ce qui manque en utilisant le module sarracenia/featuredetection.py.
Dans ce module se trouve une structure de données features, où vous ajoutez une entrée expliquant l’importation nécessaire et les fonctionnalités qu’il apporte à Sr3. Vous ajoutez également les protections if feature[‘x’][‘present’] dans le code où vous utilisez la fonctionnalité, afin de permettre au code de se dégrader avec élégance.
Si la dépendance est ajoutée dans un plugin, alors il y a aussi une méthode pour celle décrite ici :