sispheor a écrit 15 commentaires

L'échange se fait en HTTPS. Et les droits peuvent être gérés finement dans AWX via les RBAC associés au token que vous allez créer pour Squest.

Il faudrait genre ajouter la traduction FR de la section "hello world" du readme ici.

Le mettre juste après "contexte" je pense.

C'est ma faute aussi. Je baigne dedans et du coup j'ai pas pensé à mettre cette chose essentielle qu' est le hello World.
Faudrait que je contacte la rédaction pour voir si je peux modifier la dépêche.

En réalité molécule ne test pas vraiment. Il exécute le playbook dans un env conteneurisé et vous demande de "vérifier" par vous même après coup que le résultat final est bien celui attendu.

J'aurais dû mettre le hello World de la doc.
Monkeyble ne demande pas de modification du playbook ou rôle. Il va exécuter le playbook et vérifier tâche par tâche les entrée ou sortie.
Le mock aussi présent dans la doc permet de valider par exemple les inputs sans pour autant vraiment exécuter le module.
Par exemple vous avez un module pour créer une VM vous voulez juste vérifier que la tâche aurait été appelé avec les bons arguments.
Faut faire un tour sur la doc pour mieux visualiser.

L'argument du signing est meilleur que celui du problème de l'execution de code que vous avez mentionné en premier lieu.

Mais meme un paquet signé par un éditeur peut contenir a son insu des problèmes dans des librairies qu'il utilise pour son propre fonctionnement.

C'est parce que la le pip3 utilisé est celui du système. Les paquets vont être installés dans sites-packages qui n'est accessible qu'en root.
Mais après il est possible de faire un venv pour mettre ces libs dedans sans sudo effectivement.
La comme c'est des outils de base qui ne vont pas beaucoup bouger je me permets ce raccourci.

Je ne suis pas d'accord avec ça. Vous pensez que du code malicieux ne peut être présent que d'en du Bash?
Bien sûr que non.
Avez vous lu entièrement le code de votre navigateur ? Le code de votre kernel linux? Le code de votre OS?
Non.
Et pourquoi ?
Pas parce que c'est du Bash. Mais parce que vous faites confiance à la source.
Si vous faites confiance en la source alors vous n'avez pas à lire tout le code.
Du code malicieux peut être distribué par pleins de moyens. Ce n'est pas parce que vous utilisez un package manager que vous êtes en sécurité. Encore récemment des liens npm ont été infectées. Et python encore plus récemment avec le problème des clés Amazon.
Bref, ce n'est pas la sécurité que de ne pas faire du curl Bash. Sinon les grands mastodontes sur le web pour des gros projets le feraient justement plus.

C'est quoi le problème avec curl Bash ?

Squest a une API. Qui pour le moment ne couvre pas 100% des appels. Mais cela va venir.
Par la suite nous pensons ajouter un module Ansible mais pas de terraform en vue pour le moment.
Je vous invite à parcourir la doc pour voir les possibilités déjà disponible.

Et bien je veux bien connaître les noms des outils que vous utilisez pour justement remplacer les feuilles Excel.
Nous avons testé pas mal de choses et n'avons pas trouvé notre bonheur jusque là mais on est peut être passé a côté.
Nous avons Netbox qui nous permet de gérer le network et les devices physiques.
Après notre outil n'est qu'une copie de "Red Hat Service Catalog". Je vous invite à aller voir leur page pour + d'info.
Il est basique, certe, mais répond à notre besoin.
Et comme nous avons opté pour une approche générique nous avons décidé de l'offrir à la communauté open-source.

Vous pouvez mettre se que vous voulez.
Les resources pools sont juste des objets génériques auquel vous associez des attributs comme vcpu ou mémoire.
Les attributs aussi sont génériques.

Le but ici est de faire en sorte que squest soit le source of truth de l'infrastructure.
Cette fonctionnalité remplace en quelque sorte le fichier excel que tout le monde fait pour suivre ce qui a été demandé. Avec l'avantage de proposer une vue et façon de faire unique et ainsi éviter de se retrouver avec pleins de fichiers Exel formatés différemment.
Ce n'est pas du monitoring mais du tracking de réservation.
Le monitoring est une chose que l'on gère après avec un Prometheus par exemple afin de comparer la resource réservée et la resource réellement consommée.

Effectivement l'idée c'est de transformer n'importe quel playbook disponible dans AWX/Tower en service.
Donc base de données ou autre.
Terraform ou CI/CD. Vous pouvez tout appeler du moment que le entry point est un job template.

Du coté de Kalliopé on pensait intégrer snips en STT. je ne savais pas que c'était en réalité basé sur Kaldi.
Du coup peut être que une intégration de Kaldi directement serait le mieux.
Il y a eu des PR du coté de la lib python speeh reco, mais rien de mergé jusque la.