nutella-framework / nutella_framework Goto Github PK

https://codeclimate.com/github/nutella-framework/nutella_framework/Nutella::Runs

Data and actors can belong to:

• nutella (one instance for all applications and runs). Data in this category can be stored inside the nutella framework home dir and actors will have only one instance across all the applications, therefore every time we call nutella start/stop we need to check that they have been properly started/stopped
• applications (one instance per project used by all runs (instances) of that application). Data in this category can be stored in files inside the project directory structure. Actors in this category are started only once per project. This needs to be attacked at some point
• runs (one instance per run) Data for the runs lives in the project folder but needs to be indexed using the run_id. nutella_lib takes care of this at the client level but maybe we should think about re-writing some of nutella to use nutella lib

In general, this requires more thinking and a round of cleanup of the framework

Store them into a .pids file. If startup launches another process, then it can't be started automatically. What do we do? Think more about this.

As well as any other configuration file

• User should go to the website and download a zip file. Unzip, add to path and that's it.
• Download should be minimal and only contain the CLI. Then all the rest of the stuff is downloaded by the CLI on a "if-needed" basis.

What are the required softwares? Required softwares are only for the CLI, not for the rest. Those can be communicated by the CLI to the user.

People should be able to create projects using "recipes" or lists of templates they would like

Right now we don't check the list

Should give me `tmux attach-session -t <complete_run_id>

Should have two sub commands: validate and create
This absorbs issue #34

http://localhost:57880/roomquake works
http://localhost:57880/roomquake/ doesn't

Need to write code docs but, more importantly, guide for the users

https://github.com/nutella-framework/nutella_framework/blob/master/lib/core/commands/install.rb#L69

When doing nutella start <runid> the run_id is passed through the command line. Then a file .<runid>_runconfig is created in the project directory containing all the values that need to be picked up by the bots and interfaces. Bots using the nutella library will pick up these values as soon as they will boot. Passed values include:

• name of the run
• path to nutella installation
• the broker address (so the bots can automagically connect)
• all the variables inside nutella's config.conf

Script right now relies on which nutella but that returns null when the used didn't add nutella to PATH

Right now this fails... no no no.

$ nutella runs
Currently running 2 instances of project pippo:
 pippo
 pippo_topo
$ nutella stop pippo
Run pippo_pippo doesn't exist. Impossible to stop it.

We'll also have to prevent run_id = project_id otherwise we'll have confusion when starting/stopping

If we don't do that errors like these might happen

casper:roomquake tebemis$ nutella start rq_demo

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: listen EADDRINUSE
    at errnoException (net.js:904:11)
    at Server._listen2 (net.js:1042:14)
    at listen (net.js:1064:10)
    at net.js:1146:9
    at dns.js:72:18
    at process._tickCallback (node.js:419:13)

gem install nutella-ltg is all you have to do. Then of course we need to deal with all the dependencies but we can do that afterwards wither by simply notifying the user with nutella checkup or by wrapping the gem command into an installation script.

When you are using a reverse proxy in front of the framework, the URL get all messed up

When building zip .idea files are still there

https://codeclimate.com/github/nutella-framework/nutella_framework/Nutella::RunList

Start and stop are filled with bugs... We need to re-structure them in order to make them eject whenever there is a problem with a sub-routines. Also, stuff needs to be better compartmentalized into sub-routines

Nutella libraries need to shelter bots programmers from connection and transport issues. The only exposed primitives available arepublish and subscribe. Nutella clients automagically connect (and reconnect) as soon as the bot is started.

nutella libraries also "split" all the logged messages and send them over the net for anybody to subscribe to them

nutella libraries import the variables shared in the .run_config file as soon as they start and every time the file is changed

Like, WAT???

When validating the template we should check that, if these scripts exist, then they must be executable. https://github.com/ltg-uic/nutella_framework/blob/master/lib/core/commands/install.rb#L142-L143

What is a template

A template is simply a folder containing a nutella.json file which contains all the information necessary to us the template. This information includes:

• template name (mandatory, unique if in nutella repo)
• template version (mandatory)
• template type (mandatory): bot or interface for now
• template git repo (optional)
• template description (optional)
• requirements. This is the most interesting bit. Since templates can be written in any language each one of them requires specific tools to be run, download dependencies and what not. For this reason templates need to specify the required the tools and the version required.

Bot templates

In addition to this a bot template is characterized by three shell scripts that are used by nutella download dependencies, compile and run the template:

• dependencies: this script is optional and takes care of downloading the dependencies of the project (i.e. gem install, mvn install, npm install)
• compile: this script is optional and compiles the bots that require this step (i.e. mvn compile/package)
• run: this script is mandatory and stars the bot. See #6 for more details on how to write startup scripts.
  Nutella will only run the scripts that it finds.

Interface templates

Interface bots are more delicate and require some more thinking

Installation

The standard way to install a templates is nutella install <templateId> from within the directory of the project. The command looks into the repository of nutella templates. When you do so, nutella will search the templates database (see below) and will simply do a git clone of the repo into the current project. As easy as that...

You can always install a template by simply specifying the file path of the template like so nutella install /my/absolute/path/to/file or by specifying the git repo where the template is.

Templates Database

Templates repository is simply the templates-database branch of nutella repo containing a bunch of .json files. Each file is named after the template with the same name and contains:

• template name
• template version
• template type (bot or interface)
• template git repo
• template description

To submit a new template for inclusion in nutella you simply do a pull request to the templates-database branch and you are good to go. (And, of course, offer the template in a git repo)