In order to control the compute resources reserved for NGINX containers, we must add a new optional field into RpaasPlanSpec with this propose. I thought something like this.

import corev1 "k8s.io/api/core/v1"

type RpaasPlanSpec struct {
    ...
    Resources corev1.ResourceRequirements `json:"resources,omitempty"`
}

This way we can forward that resource request directly to Nginx.Spec.PodTemplate.Resources at Nginx CR.

It would be nice if we describe the RpaaS API using a formal specification like OpenAPI. Below is outlined all routes used today. Let's doc them! 🚀

Tsuru Service API:

• POST: /resources
• GET: /resources/:instance
• PUT: /resources/:instance
• DELETE: /resources/:instance
• GET: /resources/plans
• GET: /resources/:instance/status
• POST: /resources/:instance/bind-app
• DELETE: /resources/:instance/bind-app
• POST: /resources/:instance/bind
• DELETE: /resources/:instance/bind

RPaaS API (legacy):

• GET: /resources/:instance/plans
• GET: /resources/flavors (deprecated)
• GET: /resources/:instance/flavors (deprecated)
• GET: /resources/:instance/node_status (deprecated)
• POST: /resources/:instance/scale
• POST: /resources/:instance/certificate
• GET: /resources/:instance/block
• POST: /resources/:instance/block
• DELETE: /resources/:instance/block/:block
• DELETE: /resources/:instance/lua (deprecated)
• GET: /resources/:instance/lua (deprecated)
• POST: /resources/:instance/lua (deprecated)
• DELETE: /resources/:instance/route
• GET: /resources/:instance/route
• POST: /resources/:instance/route
• POST: /resources/:instance/purge

RPaaS v2:

• GET: /healthcheck
• GET: /resources/:instance/info
• GET: /resources/:instance/certificate
• DELETE: /resources/:instance/certificate/:name
• GET: /resources/:instance/files
• GET: /resources/:instance/files/:name
• POST: /resources/:instance/files
• PUT: /resources/:instance/files
• DELETE: /resources/:instance/files/:name
• *: /resources/:instance/exec

NOTE: These routes can be found at api/api.go file. The current OpenAPI spec is located on docs/openapi.yaml.

Today we've the nginx.conf's template inside the rpaas-controller source code. It means any needed change into nginx.conf template requires changing the source code and redeploy the controller in the cluster. That's awful.

I suggest moving this main template to a ConfigMap and associate that with a new field into RpaasPlan, e.g.

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf-template
  namespace: default
data:
  nginx.conf.tmpl: -|
    user {{with .Config.User}}{{.}}{{else}}nginx{{end}};
    worker_processes {{with .Config.WorkerProcesses}}{{.}}{{else}}1{{end}};
    include modules/*.conf;
    events {
        worker_connections {{with .Config.WorkerConnections}}{{.}}{{else}}1024{{end}};
    }
    # ...
---
apiVersion: extensions.tsuru.io/v1alpha1
kind: RpaasPlan
metadata:
  name: my-plan
spec:
  image: tsuru/nginx-tsuru:1.16.0
  nginxTemplate:
    configMapName: nginx-conf-template
    namespace: default
    key: nginx.conf.tmpl
---
apiVersion: extensions.tsuru.io/v1alpha1
kind: RpaasInstance
metadata:
  name: my-instance
spec:
  planName: my-plan

Currently, an instance (in Rpaas) can be bound for a single app (in Tsuru). We may outsmart that. Supporting many app-binds turns this project more flexible and gives the power to the user.

This issues is related to the suggestion in #16 (comment) and #16 (comment). There also describes a great way to fulfill that.

It would be nice if we run the web API under the TLS, this would make life harder for the bad guys. 🔐

We can use the config package to read the path in the system which is located the certificate and key. A good name to these is RPAASV2_API_CERTIFICATE and RPAASV2_API_KEY respectively.

Relative to tsuru/tsuru-client#172

In order to support installing the rpaasv2 plugin using the tsuru-client, this project must publish a manifest.json
The example for version v0.33.1 would the following:

{
  "SchemaVersion": "1.0",
  "Metadata": {
    "Name": "rpaasv2",
    "Version": "0.33.1"
  },
  "UrlPerPlatform": {
    "darwin/amd64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Darwin_x86_64.tar.gz",
    "darwin/arm64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Darwin_arm64.tar.gz",
    "linux/amd64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Linux_x86_64.tar.gz",
    "linux/arm64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Linux_arm64.tar.gz",
    "linux/386": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Linux_i386.tar.gz",
    "windows/amd64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Windows_x86_64.zip"
    "windows/386": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Windows_i386.zip",
  }
}

It would be nice if we could manipulate the rpaasinstance.spec.autoscale field over web API. So, we need a complete CRUD to address this one, something like:

Creating

curl -d max=20 -d memory=75 -d cpu=90 http://api.rpaas.local/resources/my-instance/autoscale

Reading

curl http://api.rpaas.local/resources/my-instance/autoscale

Updating

curl -X PATCH -d min=10 http://api.rpaas.local/resources/my-instance/autoscale

Deleting

curl -X DELETE http://api.rpaas.local/resources/my-instance/autoscale