Here are @pilou’s notes
@Blsd reports the MLA has two main challenges:
- the Ubuntu workstations are not familiar to anyone in the team
- the communication aspects (web site, newsletter, etc.) require technical knowledge
Participating in the forum and subscribing to it is a way to benefit from external help. And it works most of the time. Here is an example: the newsletter does not show as expected on some mail clients because of the CSS/HTML integration. @justinem is actively helping and there is progress towards a solution.
@loic emphasizes that technical support is a problem common to all non-profit organizations but is rarely resolved in public. It is very beneficial to other organizations when the MLA describes:
@nqb is curious about the interactions between Enough and the MLA. @loic explains he volunteered early 2020. It started with an observation period with no interaction between Enough and the MLA. A number of services were implemented for the MLA during this period, not using Enough at all. Then came the question of the maintenability of all the services in place (forum, chat, vpn, wordpress, monitoring, etc). Some of them were already provided by Enough, others were not (such as the VPN). Enough became the solution to reduce the maintenance cost of the services to the minimum. Almost all custom made services implemented at the MLA were integrated in Enough and driven by configuration files and variables instead of home made HOWTOs. This part ended august 2020. The end of the year will be about training MLA staff to use the services and ask for help effectively in public forums. A training program is now in place to achieve this goal.
@pilou presents his work with Zuul, a tool based on Ansible. It is deployed as code (no web interface). @nqb mentions https://release-monitoring.org/ uses Zuul. The Zull instance maintaned by @pilou is used to test the burp role, used to perform laptop backups at the MLA.
@loic explains the current state of the Enough CI. The tests are divided in stages because some of them take a lot of time. They require creating OpenStack VMs and volumes and deploying services via Ansible. And they are unstable… reason why we’re having this discussion.
@loic explains how and why molecule was replaced with tox and pytest (impossible to use multiple inventories, no OpenStack machine creation out of the box, no support for upgrade testing).
@loic explains that the current Docker support for the CI implemented last year is no longer functional and creates too many difficulties. It seems wiser to use libvirt which is conceptually closer to OpenStack.
@loic clarifies that Docker is used in three contexts:
@nqb asks about the context in which the CI can run with OpenStack
@loic explains the gitlab runner (which is provisioned by Enough) has OpenStack credentials and it could, in theory, run the tox -e bind test. But it fails 50% of the time because of environmental issues, which defeats the purpose.
@nqb explains he uses a CI based on a Debian GNU/Linux machine running libvirt deployed by debops. The machine is used as a shell runner for a GitLab instance. The machines are created via Vagrant files reading from a custom made YAML file which can also be used as an inventory by Ansible.
@loic will work on implementing a minimal CI run for at least one test based on libvirt in the next two weeks. @nqb will review the work done on September 25th, 2020, or sooner if he is available.
@nqb suggests to document that Enough is trying its best to be lightweight to maintain, because it influences decisions such as using k8s rather than virtual machines and docker. If k8s is perceived as significantly more complicated, it will not be considered. A counter example would be indie.host who chose k8s and developed an expertise over the years.
from 
for the