Skip to content

v0.2.5

Compare
Choose a tag to compare
@mostafa mostafa released this 15 Jan 00:41
· 1419 commits to main since this release
bca36bb

This release officially marks the end of milestone v0.2.x. This milestone had a lot of changes to the core and the plugin subsystem. The core is more robust and stable and the plugin subsystem can handle a lot of edge cases and issues manifested in the previous milestone and the features needed to be added. Here are the changes:

  1. Add command-line arguments (flags) to plugins via gatewayd_plugin.yaml config file (#75)

  2. Pass environment variables to plugins via gatewayd_plugin.yaml config file (#77)

    verificationPolicy: "passdown"
    compatibilityPolicy: "strict"
    acceptancePolicy: "accept"
    
    plugins:
      - name: gatewayd-plugin-test
        enabled: True
        localPath: ./gatewayd-plugin-test
        args: ["--parameter", "value"]
        env:
          - key=value
        checksum: b1cfe3c6b268d904abe405b106ef737da5373912586ff8a16695939c38caf30d

    The plugins can optionally opt-in to receive the required MAGIC_COOKIE_KEY and MAGIC_COOKIE_VALUE via environment variables, which can be passed via the above config file. GatewayD needs the following constants to be passed, so it verifies the plugin is valid:

    MAGIC_COOKIE_KEY=GATEWAYD_PLUGIN
    MAGIC_COOKIE_VALUE=5712b87aa5d7e9f9e9ab643e6603181c5b796015cb1c09d6f5ada882bf2a1872
  3. Add requires field to plugin config to check for loaded plugins required by the current plugin (#81)

  4. Add a new config parser for global and plugin config (#84)
    The global config file, gatewayd.yaml, contains a default object for each object except server (for now). This is the foundation to have multiple objects of the same type with different configuration for running multi-tenant servers (TBD), clients, loggers and proxy and to connect to multiple database servers at the same time for aggregations, load-balancing and related functions.

  5. Use multiple sources for configuring GatewayD including environment variables (#86)
    Multiple sources calls for order of precedence in how different sources affect the result of configurations in GatewayD. This will be the precedence order for loading and applying config:

    1. Plugin default values (lowest precedence)
    2. Plugin config file
    3. Environment variables for plugins
    4. Global default values
    5. Environment variables for global config
    6. Global config updated by plugins via OnConfigLoaded hooks: plugins override the global configs and has the highest precedence overall.
  6. Add two new hooks for controlling traffic (#94, #96 and #98):

    hook type description
    OnTraffic Notification of incoming traffic from the client.
    OnTrafficFromClient Traffic is received from the client. This can terminate the connection.1️⃣
    OnTrafficToServer Traffic is sent to the database server.
    OnTrafficFromServer Traffic is received from the database server.
    OnTrafficToClient Traffic is sent to the client.

    1️⃣ As explained here, it is now possible to terminate the connection before the request even reaches the database server. To achieve this, the plugins needs to have the OnTrafficFromClient RPC endpoint and also expose the hook in their config. Then they can achieve connection termination by setting two variables in the return value of the RPC endpoint:

    return structpb.NewStruct(map[string]interface{}{
        "terminate": true,
        "response":  base64.StdEncoding.EncodeToString([]byte{'X', 0, 0, 0, 4}),
    })

    The terminate variable instructs the proxy to stop sending the received data (from client) to the server. The response variable will be sent back to the client, instead. If there is no response in the return value, the connection from the client will close abruptly.
    The use case of the second change mentioned above is to let plugins stop requests from reaching the server, for example in a cache plugin scenario, the plugin should decide whether to return the cached value (of a query, which is the previous server's response) or let the message reach the server (and cache it afterwards). This is now possible using connection termination.

  7. Recycle available connections using an internal in-process scheduler (#101) to avoid having stale and timed-out connections in the pool of available connections

  8. Add custom hooks and the OnHook method for plugin to process those custom hooks #110

  9. Add log file rotation #115 (current release)

  10. Other changes, fixes and cleanups: #80, #82, #104, #105, #106, #109 and #117.

Full Changelog: v0.2.4...v0.2.5