BeagleBoard/GSoC/Bonescript remote deployer

Bonescript zero-configuration and user-friendly remote deployer utility, to help manage remote boards scripts

Student: Francesco Guardiani GSoC: GSoC entry

=Status= This project is currently just a proposal.

=Proposal= Please complete the requirements listed on the ideas page and fill out this template.

About you
IRC: francesco_guardiani Github: slinkydeveloper School: Politecnico di Milano Country: Italy Primary language Italian Typical work hours 5PM-10PM CET

Description
I would have the pleasure to implement the idea described in this issue. The main objective of this task is to create a user-friendly zero configuration remote deployer, simple to use as: This command is intended to use with BeagleBone/BeagleBoard directly connected to network via one of its network interfaces (WiFi or Ethernet). This command will do this following steps: Creating a systemd unit will be useful to remotely manage the deployed instance of script via SSH tunnel. For this purpose, I will create a wrapper command for systemd remote interface: At the first run  generates a configuration file, called. This configuration file enables user to configure all the parameters for remote deploy like: A script called  will help the user to configure the   file The usage of the configuration file can help the user to deploy on a batch of BeagleBone/BeagleBoard the same script, and with the  the user can watch status of script at the same time on all machines deployed. After the first usage (or after the manual creation of the configuration file via a command like ) the user can use the deployer command without having to specify every time the host and port. Also I will expose an API to do all those things inside scripts created by users
 * Instantiate SSH connection with standard parameters (username root and no password).
 * Upload project files in current directory to pre-defined directory in BeagleBone/BeagleBoard
 * Configure a new systemd unit to run the bonescript project.
 * Execute the systemd unit and print a hopeful “It Works” in client side
 * Multi machine configuration
 * Alias, host, port, username and password for every BeagleBone/BeagleBoard configured
 * Script to run on BeagleBone/BeagleBoard before/after successful deploy

Project Structure
As seen before, the project is divided into three scripts ready to use for the final user: All this scripts rely on one configuration file for project: allows the user to run the algorithm that uploads the project to remote machine/machines. This algorithm will rely on SSH tunnels to connect with remote machines. This choice allows the use of bonescript remote deployer without configure remote BeagleBone/BeagleBoard, reaching the most important objective of this project: the give to the final user a friendly and plug & play interface. The sample procedure of what this command will do is described here: If no  file exists, the command automatically calls   with parameters provided by parameters   and. Before copying project files to server, the command will generate a systemd unit that will be installed on remote machine and will save that in local project folder. If it already exists, no file will be created so user can modify the systemd unit automatically generated. After generation procedure the command calls the algorithm that deploys script on remote machine. This will be a simple copy-paste procedure that copy entire project folder from user machine to BeagleBone/BeagleBoard. The functionality of file transfer will be achieved by SCP protocol. The final step of  is to copy the systemd unit to pre-defined folder and start the service. is the command that enables user to manage his script deployed on remote BeagleBone/BeagleBoard. The reasons of choice to rely on systemd for remote software management are: With systemd remote control (or with SSH connection) the user can connect to one or all boards configured at the same time and start, stop, enable for start at boot and so on. Also systemd provides script logging and this functionality, combined with remote connection, can take advantage of enable the user to watch the status of his script as simple as    will help user to manage the configuration file. It will expose functions as add machine, remove machine and generate the configuration file (like ). configuration file will be a JSON file containing an array that contains boards informations. Other configuration parameters can be added later.
 * Having a robust and affordable framework to manage locally and remotely the script
 * Granting zero configurations : as for SSH, user doesn’t need to configure a “remote software manager”, because distros primarly used on BeagleBone/BeagleBoard (like Angstrom Distribution) already has systemd locally installed

All this command will be implemented in Node.JS, using libraries with open-source license compatible with BoneScript project

Timeline
1 May – 31 May: Join the Beagleboard community and design all technical aspects of the project with the help of mentor 1 June – 26 June: Create a first working prototype of bonescript-remote-deploy with file upload, generation of systemd and start of script (without configuration file) 26 June – 24 July: Create bonescript-remote-manage and test it 24 July – 10 August: Configure the previously defined commands to support configuration file and create bonescript-remote-config 10 August – 21 August: Complete the project test with multi boards deployment test and fix bugs

Experience and approach
I already work with these technologies, in particular I worked a lot with Node.JS (like described before). Moreover I have good knowledge of systemd (every project I coded uses the systemd as deamon manager) and SSH. My obsession is coding a project working in all its aspects and features, for this reason I test every module/functionality of my project before committing to repository. I love bringing into a project new features with the main objective of simplify the final user experience.

Benefit
The main benefit for the community is the usage of a simple remote deployer that enables users to update entire networks of boards with one simple command. Also the remote management feature enables users to update the code when they don’t have physical access to the board. Some example are shown here:
 * Update script of a sensor reader inside a sensor network
 * Manage status of remote script and, in case of crash, remote reupload a working version of the script