Aujourd’hui, quand on parle d’API, on pense en général aux API REST. Elles sont omniprésentes, utilisent des protocoles et des formats standard, reposent sur des bases solides... Pour l’administrateur système, une API REST de type Redfish permet, par exemple, de se constituer aisément une interface de gestion hors bande multi-constructeurs. Pour autant, dans certaines situations, des contraintes peuvent empêcher de recourir à une API REST. Notamment lorsque votre système n’est pas directement accessible via le protocole HTTP. Dans ce cas, vous pouvez bien sûr toujours utiliser une API, mais reposant sur d’autres standards, comme le vénérable protocole SMTP ! Dans notre cas pratique, un système d’atelier de formation à la demande, c’est un front-end Web qui gère l’enregistrement des utilisateurs afin d’exécuter les documents Jupyter Notebooks hébergés sur un back-end accueillant l’instance Jupyterhub ainsi que tous les systèmes d’accompagnement nécessaires à la réalisation des différents ateliers proposés (sur Redfish, Git, Rust comme affiché sur https://hackshack.hpedev.io/workshops et via le portail de démo HPE WW https://hpedemoportal.ext.hpe.com/) Pour que tout ceci fonctionne parfaitement, nous avons utilisé une API SMTP, le front-end générant le contenu SMTP et le back-end utilisant procmail, des scripts et des playbooks Ansible pour gérer la configuration de l’environnement utilisateur. Une fois connecté à la plateforme, l’utilisateur peut accéder au contenu d’atelier qui lui est propre, tous les liens vers les autres systèmes étant disponibles pour effectuer les actions. Pourquoi SMTP ? Nos besoins étaient suffisamment limités pour éviter le développement d’une API REST complète (même si nous en avons également une pour le front-end), nous bénéficions gratuitement de l’aspect asynchrone de l’e-mail pour la gestion des demandes et c’est sympa d’utiliser les bonnes vieilles méthodes pour montrer aux jeunes ingénieurs qu’il existe plusieurs de faire ;-) Ça vous tente ? Venez donc découvrir comment nous avons procédé et voir comment tout cela fonctionne, depuis le déploiement automatique de la plateforme jusqu’à l’exécution d’un atelier.

1. API != REST - PROCMAIL TO THE RESCUE
By HPE DEV Team
and HPE CIC Team

2. 2
Introducing Bruno Cornec
●
Software engineering and Unices since 1988:
– Mostly Configuration Management Systems, Build systems, quality tools, on multiple Unix systems
– Discovered Open Source & Linux (OSL) & made first contributions in 1993
– Full time on OSL since 1995, first as HPE reseller then @HPE
●
Currently:
– OSL Technology Strategist in HPE WW Customer Innovation Center, Grenoble, France
– WW Linux Community Lead for the HPE Open Source Profession
– Conferences at WW level at LinuxCon, Linux.conf.au (2007, 2013, 2014), Fosdem, RMLL POSS, ...
– MondoRescue, Project-Builder.org, python-redfish, UUWL and PUSK Project Lead
– LinuxCOE, mrepo, tellico, rinse, fossology, collectl, Ironic contributor
– FOSSBazaar/SPDX and OSL Governance enthusiast
– Mandriva, Mageia, Fedora packager
●
And also:
– Amateur singer (Alto / Tenor), recorder player since 1976 and Choir director since 1987, CD collector (7500+), Concerts, Photography

3. 3
Introducing Frédéric Passeron
●
20 years @HPE in presales organizations
●
Strong focus on solutions (HP Toptools, HPSIM, Matrix, HP CloudSystem,
HP Helion Openstack, HPE OneSphere HPE Ezmeral)
●
Currently:
– HPE Dev Experience team Solution Architect
– Hack Shack Workshop on Demand (WoD) Program Manager
– Vlub project management
– Volumio contributor
●
And also:
– High end HI-FI systems fan (see video !)
– Musical Streamer builder
The Hack Shack@KubeCon
A place for developers to gather
Inviting atmosphere
Informative and fun
Physical now virtual
Workshops
Hands-on training
On-demand
Use of Jupyter notebooks
Challenge
Augments workshop material
Prizes offered for creativity
Replays
Community
Popular Hack Shack Attack game
It was announced at KubeCon Austin in
December 2017
Main goal: “Accelerate Innovation
through Sharing , Communicating and
Collaborating among members of the
developer community”

4. 4
Why a Mail API ?
● End of 2019 :
– Need for a new way of delivering labs, Workshops:
– Move away from pdf and putty sessions…
– Jupyter Technology looked interesting:
● 2020 Covid 2019 Pandemy
– Need to accelerate to support virtual Events (TSS 2020, HPE
DVE 2020, KubeCon...)
– Build up first two jupyterhub servers (Staging and prod)
– Many manual processes to handle workshop management @
first
– One ANSIBLE Playbook to distribute notebooks over the
different Students and a few scripts…
– No Registration Portal
– No Automation
● First Beta after Discover 2020
– First registration portal and early works on Mail API
– Pilot in October 2020
● Production in October 2020
– More than 1500 Workshops delivered since October 2020

5. 5
INFRASTRUCTURE
IN PLACE
Jupyterhub Server
(postfix + procmail)
A single DL360 Gen10 Server
Infrastructure hosting API
Endpoints
• HPE OneView Appliances
• Nimble Virtual Arrays
• HA HPE Container Platform MLOPS
• Aruba OVAs
• Redfish/OpenBMC VMs
https://hackshack.hpedev.io/workshops
Registration portal - Netlify
2 student &
notebook setup
(smtp API)
6 training
(http)
7 appliances
interaction
(REST API)
1 WoD
(http)
3 appliances setup
(ssh+REST API)
2 and 4 back-end
update
(REST API)
5 user info
(smtp)

6. 6
A MAIL API, REALLY ?
•Not all systems are https reachable (security)
•Mail provides some advantages over https
– free queuing system
– Passes complex network setup
•Procmail helps manage API mail requests
– Easy input filtering
– Easy parameters management
– Script called from procmail to perform actions
•Tests are easy to perform

7. 7
ANSIBLE + NOTEBOOKS
●
Ansible is used for
– Platform installation
– Platform conformity and convergence
– Student setup including notebooks instantiation
●
Usage of variables to support multi-site
– Sandbox, staging, production, dev, ...
●
Usage of Jinja2 features to individualize notebooks

8. 8
LIVE VIDEO EXAMPLE
IT'S SHOW TIME FOLKS !

9. 9
THERE'S MORE AND WHAT'S NEXT ?
●
Everything under private git
●
25 Workshops in production
●
Built on Ubuntu 20.04 + Jupyter kernels
– python, bash, powershell, go, rust, java, ansible, ssh
●
Future steps:
– 2 more workshops per month
– Improved CI/CD (automated tests per commit)
– CentOS port (Done mostly)
– Docker spawner for Jupyter
– NoteBook completion Measurement (Ongoing)
– Open Sourcing
– More Notebooks (Ongoing)

10. 10
BUILD | COMMUNICATE | COLLABORATE
hpedev.io
Yammer Group (Partner)
hpedev.slack.com
Monthly Newsletter
mailto:hpedev@hpe.com
@HPE_DevCom
Yammer Group (Internal)
Workshops-on-Demand

11. THANK YOU
Frederic.Passeron@hpe.com
Bruno.Cornec@hpe.com