API != REST - procmail to the rescue
Blemings Labs | Sat 23 Jan 10:45 a.m.–11:05 a.m.
Presented by
-
Bruno Cornec
https://brunocornec.wordpress.com/
Bruno Cornec is Engineer of the French Ecole Centrale de Lyon, France (1987)
He has been managing various Unix systems since 1987 and Linux since 1993 (0.99pl14)
Bruno first worked 8 years around Software Engineering and Configuration Management Systems (Build systems, Quality tools) in Unix environments. Since 1995, he is Open Source and Linux (OSL) Technology Strategist and Evangelist, initially for an HPE reseller and since 2000 for Hewlett Packard Enterprise.
Bruno is a contributor to various OSL projects: MondoRescue (2001), Mageia (2003), LinuxCOE (2006), Pause (2007), Tellico (2008), FOSSology (2008), collectl (2009), Ironic (2015), python-redfish (2015). He is also project leader for MondoRescue (GPL disaster recovery solution, 2005), dploy.org (GPL deployment server, 2006), project-builder.org (GPL build service, 2007), UUWL (LGPL/MIT Unix to Unix Wrapper Library, 2011), PUSK (GPL ProLiant USB Setup Key, 2012), python-redfish (Apache, 2015).
He has also been a board member of the AFUL and OpenStack-fr associations. He's president of the FLOSSITA association.
As part of his work he has made numerous presentations for Solution Linux/OWF/POSS in France, and WW at LinuxCon/Open Source Summit, RMLL/Libre Software Meeting, Linux.Conf.au, OSCON, Linux Symposium, Fosdem around various topics (High Availability, Deployment solutions, System management, Disaster Recovery, Package building, Cloud...)
Outside computers, Bruno also likes early and baroque music, singing and playing the recorder. He's married and father of 3 kids.
-
Frederic Passeron is a solution architect in the HPE DEV Experience team, where Frederic promotes the Dev Community Program though several means such as events, workshops, blogs...
Frederic has been working for HPE for the last 20 years in presales organizations at different levels, from country (France) to region (EMEA) and now worldwide with a strong focus on solutions since the early days of HPSIM, Matrix, HP CloudSystem, and Helion Openstack to name a few. He is now working on evangelizing the HPE DEV Community Program.
When he isn’t working, you’ll find Frederic reading a book while listening to some cool records on his high end HIFI system. Else, he'll probably be working on some diy project like building a new Musical Streamer or fixing a vintage turntable.
Bruno Cornec
https://brunocornec.wordpress.com/
Abstract
These days, most people speaking APIs think REST API. It's ubiquitous, uses standard protocols and formats, based on giants shoulders...
For the sysadmin REST API like Redfish is a nice way to have a cross-manufacturer out of band management interface e.g.
However in some case, you have constraints that do not allow you to use a REST API. When your system is not reachable directly using the HTTPS protocol e.g. In that case, you can still use an API of course, but based on other standards, such as the venerable STMP one !
Our use case, a training on demand workshop system, involves a Web front-end to manage user registration to run jupyter notebooks hosted on a back-end hosting the jupyterhub instance as well as all the companion systems needed to perform the various workshops proposed (on Redfish, Git, Rust as visible on https://hackshack.hpedev.io/workshops)
So to make it work flawlessly, we used an SMTP based API, the front-end generating the SMTP content and the back-end using procmail, some scripts and ansible playbooks to manage the setup of the user environment. Once logged on the platform, the user has acces to its own workshop content, with all the links to the other systems available to perform the actions. Why SMTP ? Well our needs were small enough to avoid developing a full REST one (even if if have also one for the front-end), we benefit from the asynchronous aspect of e-mail for free in the management of requests, and it's fun to use old methods to show young engineers that there is more than one way to do it ;-)
Interested ? Well come to hear how we did that and we'll show you how it works, from the automatic deployment of the platform up to the run of a workshop.
These days, most people speaking APIs think REST API. It's ubiquitous, uses standard protocols and formats, based on giants shoulders... For the sysadmin REST API like Redfish is a nice way to have a cross-manufacturer out of band management interface e.g. However in some case, you have constraints that do not allow you to use a REST API. When your system is not reachable directly using the HTTPS protocol e.g. In that case, you can still use an API of course, but based on other standards, such as the venerable STMP one ! Our use case, a training on demand workshop system, involves a Web front-end to manage user registration to run jupyter notebooks hosted on a back-end hosting the jupyterhub instance as well as all the companion systems needed to perform the various workshops proposed (on Redfish, Git, Rust as visible on https://hackshack.hpedev.io/workshops) So to make it work flawlessly, we used an SMTP based API, the front-end generating the SMTP content and the back-end using procmail, some scripts and ansible playbooks to manage the setup of the user environment. Once logged on the platform, the user has acces to its own workshop content, with all the links to the other systems available to perform the actions. Why SMTP ? Well our needs were small enough to avoid developing a full REST one (even if if have also one for the front-end), we benefit from the asynchronous aspect of e-mail for free in the management of requests, and it's fun to use old methods to show young engineers that there is more than one way to do it ;-) Interested ? Well come to hear how we did that and we'll show you how it works, from the automatic deployment of the platform up to the run of a workshop.