Since most RpaaS API operations are asynchronous , maybe its a good idea implement retry on celery tasks. Today the only way available is remove instance and create it again :(

RpaaS should check for any instance task lock before removal process start

It would be nice to pass a local file to the content argument as it may contain multiline content.

When we try to bind a rpaas instance that has already been binded to another one it shows me a msg and an error:

Error: Failed to bind the instance "rpaas-be-lab/teste" to the app "myapp2-static-galeb":

Internal Server Error

This dont tell me that it has been binded to another app.

The API should be able to automatically heal failing instance, respawning if needed.

When a fail occurs on host add, rpaas destroy all healthcheck even if there is others hosts on load balancer.

We should be able to run instances and manage load balancers in Amazon EC2.

The API should support plans. A plan could define things like:

• the IaaS (VM + load balancer)
  • including some settings on the IaaS (size of the VM, load balancing policy, etc.)
• the reverse proxy technology (which we call "manager" today, currently only nginx is supported)
• HTTPS support (?)

RpaaS should support some mechanism for Session Ticket Resumption - maybe a task for create and renew a session key only for ssl enabled instances

Custom location with some utf-8 char leads to a encoding error on server side

now if I scale up or down the service, we can't see the number of instances

Removing an instance with a stale removed plan lead to a PlanNotFoundError error. RpaaS should ignore invalid plan on instance removal.

would be nice to have a parameter to see the access logs, error and proxy

Env vars set on custom plan are not being used on service instance removal - only on instance creation.

admin plugin should support change instance current plan

Currently, in order to force HTTPS, we need to do something like this:

% cat rules
location / {
    if ($scheme = 'http') {
        return 301 https://$http_host$request_uri;
    }
    proxy_set_header Host app.tsuru.company.com;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_pass http://app.tsuru.company.com:80/;
    proxy_redirect ~^http://app.tsuru.company.com(:\d+)?/(.*)$ /$2;
}
% tsuru rpaas route -i instance -p / -c "`cat rules`" add
route successfully added

The magic happens at:

    if ($scheme = 'http') {
        return 301 https://$http_host$request_uri;
    }

But as we're overriding the / location, we need to ensure that we add all the rules created automatically by rpaas (how to know them? check it out).

We need:

• a command to force https on bound applications, so we customize the default location entry
• a flag in the route add command to force https in custom routes

It's not a plugin-only change, it also demands changes in the API.

When checking for status of a brand new rpaas instance we receive an 404 HTTP error message. It could be a better message:

tsuru rpaas status -s rpaas-be-lab -i teste
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 558, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

When I try to list routes on my RPaaS plugin shows nothing.

$ tsuru rpaas route -s rpaas-service -i rpaas-instance list
path: destination

But on tsuru service-info it appears.

When rpaas is used as a tsuru router, we should accept scale, plan, custom location and custom blocks as router-opts, which might be updated at any time.

Using more than 2 zones is not working - rpaas ignores CUSTOM_VAR_2 and so on when set more than 2 zones.

It would be nice to be able to view/change user quota for creating rpaas instances.

Actually, nginx reload status only lies on consul. User should be able to view nginx reload status for each instance member (probably via rpaas plugin).

Currently, we use DAV for managing the configuration of nginx, which means that we have one route for uploading the configuration file, and another for reloading nginx. It works, but is definitely non-elegant.

We could use something like consul-template or confd for dynamically manage the configuration. This would allow us to customize other parts of the configuration as well, and have certain changes that trigger a restart instead of a reload.

We have to create docs about how RPaaS works, and how plugin works.