candango / firenado Goto Github PK

Layout a basic documentation structure to the project.

Let's make the management task be able to gracefully shutdown the application.

To start an Firenado Tornado application I use this command:

$ firenado-admin app run

When application receives a shutdown signal than it runs over all components and execute a method to shutdown all blocking resources if required.

Please follow this gist: http://tornadogists.com/4643396/

The initialize method must be called even if the component has no config file.

Add a root path to the assets component. That will make possible to use assets located outside the project path.

If the root path can be absolute or relative to the project path.

Load components defined into the configuration files.

The management command help is broken. It should be fixed in order to be displayed according the command context.

It looks like the usage parameter it is not working as well.

This task will be a full refectory once we decided to replace the ini files used on iFlux to yaml config files.

This move will make us develop a less complicated config loading structure and give to the end user the ability to add custom configuration items without need to hook up functions or classes in the process. With that the risk to end up in a circular reference hell.

The reason why this will be possible is because yaml is parsed generating a tree composed by lists and dictionaries by default.

A yaml file is more readable than an ini file trying to emulate hierarchical structures.

Create the component to provide application info.

Since firenado.util.random_string was fixed to support Python 3 the function enters in a deadlock state while generating random strings.

Migrate iFlux security to Firenado

We want to make it possible to start a Tornado Application forking more than one process as an option.

To do data it is necessary start the application using bind than calling start. As listen is just a shortcut to bind/start let's start an app like that and provide options to fork the process via configuration file.

See: http://www.tornadoweb.org/en/branch2.3/netutil.html#tornado.netutil.TCPServer.bind

A component will have a method called get_ui_modules returning None.

If the developer wants to provide to the application one just override this method and return the ui_module in this method.

All components will be added to an application ui_module list at the application init and that will be added to the tornado settings.

The scheduled component will hold schedulers that will manage scheduled jobs.

Right now we'll provide a scheduler from conf but let's keep an infrastructure for other times of schedulers.

Make it possible to set the application to run in debug mode via a configuration item in the app section of the firenado configuration file.

Create the management task to run applications.

Migrate iFlux data structure to Firenado.

Provide the static_path configuration under the app section of the application config file.

When a list of socket is provided in the app.socket config than used add_sockets instead of add_socket.

See: http://www.tornadoweb.org/en/branch2.3/netutil.html#tornado.netutil.TCPServer.add_sockets

Using served_by decorator using class reference will throws an error:

/home/.../virtualenv/diaspora/bin/python /home/.../source/candango/diasporapy/diasporapy/scripts/devel_setup.py
Traceback (most recent call last):
File "/home/.../source/candango/diasporapy/diasporapy/scripts/devel_setup.py", line 51, in
dev_setup_exec.create_accounts()
File "/home/.../virtualenv/diaspora/lib/python2.7/site-packages/firenado/core/service.py", line 62, in wrapper
service_name = service._name
AttributeError: type object 'AccountService' has no attribute '_name'

On the line 62 it supposed to be used 'name' instead of '_name'.

Work with python-socketio instead.

See: https://github.com/miguelgrinberg/python-socketio

See also: https://socket.io/docs/v4/

Please follow:

• https://github.com/sockjs/sockjs-client
• https://github.com/MrJoes/sockjs-tornado

Right now we handle reasonably well the first level of commands at the management infrastructure but right now it will be necessary to route commands at the second level and maybe on the next levels.

A sub-command should be added to the management structure so we can route commands to sub-commands until a task be provided and we executed it.

For instance, to execute this command:

firenado-admin init

The management component will look for the command 'init' and if exists, run the task attached to it.

But right now we are moving to this syntax:

firenado-admin project init

Now the management component will route to the command 'project' to a sub-command init. The init sub-command will provide a task that will be executed. The desire here is to make commands route to another sub-command or execute itself.

Review the iFlux Tornado infrastructure and write down a better on Firenado.

As long Firenado may be serving other's web frameworks the structure we put here must be flexible and customize-able enough to support other options.

Tornado still be used as the default option on Firenado.

Create a command to install all components registered in an application.

The command will be:

firenado app install

A firenado component will have the install method and if the developer override this method than the logic will be executed by the 'app install' command.

Make served_by decorator receive a reference from a service

While running an application with Firenado 0.1.1 installed with pip I got this error:

[#278]>>> firenado app run
Traceback (most recent call last):
  File "/home/.../diaspenv/bin/firenado", line 9, in <module>
    load_entry_point('Firenado==0.1.1', 'console_scripts', 'firenado')()
  File "/home/.../diaspenv/lib/python2.7/site-packages/firenado/core/management/__init__.py", line 38, in run_from_command_line
    exec('import %s' % commands_conf['module'])
  File "<string>", line 1, in <module>
  File "/home/.../diaspenv/lib/python2.7/site-packages/firenado/core/management/commands.py", line 19, in <module>
    from firenado.core.management import tasks
ImportError: cannot import name tasks

Force application to recognize what module is the application module.

As a user I want to have an option to start a server listening on unix socket.

User this gist as a guide: https://gist.github.com/superduper/5579037

Define a sqlalchemy using parameters instead url.

Paremeters are:

• db or database
• driver
• host
• pass or password
• port
• user or username

This method will be helpful when we have a '@'(for instance) in the password. With the url parameter only that will cause an error while connecting to the database. The password will be always url quoted to avoid this kind of problem.

We could fix the url also but that this will be covered in another ticket.

For an url based datasorce like this:

data:
  sources:
    - name: storage
      connector: sqlalchemy
      dialect: postgresql+psycopg2://myuser:[email protected]:5432/thedatabase

We can use this kind of representation:

data:
  sources:
    - name: storage
      connector: sqlalchemy
      dialect: postgresql
      driver: psycopg2
      username: myuser
      password: thepassword
      host: 127.0.0.1
      port: 5432
      database: thedatabase

The strategy here is to convert the parameters to it's respective url notation with password being always url quoted.

Let's do the happy path with this ticket and handle mandatory parameters exceptions later.

Migrate the scaffolding structure from the iflux projet to the firenado. On firenado the module will be renamed to management.

A tornado application can be executes raw "as is" but some times(or most of the times) it is desirable to play or attach another ioloop while starting the application for instance.

Let's create types where Firenado can start an application.This configuration will be set at the app config section and will make it easy to change how the application behaves during the initialization.

The requirements necessary to run Firenado aren't wired to the setup structure and that's the reason why pip isn't installing tornado and pyyaml.

Migrate setup script from the iFlux framework to this project.

Migrate iFlux template module to Firenado.

Provide a full OpenID server functionalities with this component.

Let's start with pyoidc.

See:

• https://github.com/rohe/pyoidc/
• http://openid.net/

Firenado conf must be able to look after config files with the yml extension too.

Logging configuration should be on the configuration to make easier to control log levels and format produced by the application and the framework.

The way the session write decorator is written the handler on_finish method will be executed after the session write.
The code inside the on_finish method will use a session that won't be persisted. Let's change the decorator so the session write be executed after the handler on_finish.

Add python 3 support to the framework.

Migrate iFlux session structure to Firenado

It is necessary to show some warning when Redis server is down and Firenado try to establish the connection.

Some links to start:

http://www.tornadoweb.org/en/stable/guide/structure.html#structure-of-a-tornado-web-application
http://www.tornadoweb.org/en/stable/web.html#tornado.web.Application
http://www.tornadoweb.org/en/stable/guide/running.html#static-files-and-aggressive-file-caching

Move the log structure on conf in iFlux to the core.log.

Static maps will map any lib. The way we're mapping bower(when this component used to be called assets) could be used to map other applications/libs.

The static maps is another way to get static resouces mapped without changing the application or the component, the user will be able to map static content using the static_maps.yml/yaml file.

Redis shouldn't be a framework requirement but the application requirement because an developer could choose to use file based session or even don't use session at all.

It is necessary remove redis from the requirement list and generate a requirements.txt with the redis requirement on it.

The assets component has the hability to store bower dependencies and map them to a proper static handler so it can be accessed on the web.

It would be good to have the hability of generate a bower.json file from those dependencies mapped on the assets component config file istead of managing dependencies in 2 files.

The conf execution is looking for a components item in the configuration file.

On the firenado/conf/firenado.yaml has parent item component and that is preventing from the framework defined components to be loaded.

Set travis as the CI on firenado.

Some links to start:

http://www.tornadoweb.org/en/stable/guide/running.html#running-behind-a-load-balancer
http://www.tornadoweb.org/en/stable/httpserver.html#tornado.httpserver.HTTPServer