Prep release

Ctl/VERSION

@@ -1 +1 @@
-1.14.0
+1.15.0-rc.75

Ctl/dev/docker-compose.yml

@@ -1,7 +1,7 @@
 version: "3"
 services:
   postgres:
-    image: "postgres:12"
+    image: "postgres:14"
     environment:
       POSTGRES_DB: fullctl
       POSTGRES_USER: fullctl
@@ -297,4 +297,4 @@ services:
 
 volumes:
   postgres_data:
-  victoria-metrics-data:
+  victoria-metrics-data:

Dockerfile

@@ -1,6 +1,6 @@
 ARG python_ver=3.11
 ARG base_repo=python
-ARG base_tag=${python_ver}-alpine
+ARG base_tag=${python_ver}-alpine3.20
 
 ARG install_to=/srv/service
 ARG poetry_pin="==1.5.1"

docs/settings.md

@@ -20,6 +20,11 @@
 - `PEERCTL_URL` - host url for peerctl service (e.g., "https://peer.fullctl.com")
 - `PREFIXCTL_URL` - host url for prefixctl service (e.g., "https://prefix.fullctl.com")
 - `DEVICECTL_URL` - host url for devicectl service (e.g., "https://device.fullctl.com")
+- `BRIDGE_OBJECTS_CHUNK_SIZE` - Size of chunks for objects when making bridge requests
+
+### Logging
+
+- `AUDITCTL_LOG_API_ACTIONS` - set up logging of REST api actions to auditctl. Should be a comma separated list of ref tags or ref_tag:action pairs. For example, `ix` or `ix,member` or `ix:create,ix:delete,member:delete`.
 
 ### Operational
 
@@ -42,3 +47,19 @@
 - `BILLING_INTEGRATIOON` - if False will disable all billing checks
 - `SERVICE_TAG` - should be the service reference tag (e.g., 'ixctl')
 - `USE_LOCAL_PERMISSIONS` - if `True` permissions will be handled locally instead of through aaactl.
+
+### Support
+
+- `CONTACT_US_EMAIL` - email address to send contact us messages to, defaults to `SUPPORT_EMAIL`
+- `SUPPORT_EMAIL` - email address to send support messages to, defaults to `SERVER_EMAIL`
+- `POST_FEATURE_REQUEST_URL` - url to post feature requests to
+- `DISABLE_FEATURE_REQUEST` - if `True` will disable the feature request form
+- `DISABLE_HELP_MENU` - if `True` will disable the help menu in the lower right corner
+- `DISABLE_CONTACT_US` - if `True` will disable the contact us form and link
+- `DOCS_URL` - url to the documentation
+- `LEGAL_URL` - url to the legal page
+- `TERMS_OF_SERVICE_URL` - url to the terms of service page
+- `PDB_OAUTH_PROMPT_LINK` - controls how call to action for linking a peeringdb account is displayed
+    - `never` - never show the call to action
+    - `no_asn` - only show if there are no ASN authorizations
+    - `always` - always show if there are no linked PeeringDB accounts

docs/tasks.md

@@ -242,8 +242,53 @@ manage.py fullctl_promote_user vegu -Q
 
 Fetch and process tasks in the task queue using the `fullctl_poll_tasks` command
 
+## Workers
+
 ```sh
 manage.py fullctl_poll_tasks --workers 4
 ```
 
 This will run forever and automatically fetch and process tasks that the environment is qualified to handle.
+
+## Self selecting workers
+
+```sh
+manage.py fullctl_poll_tasks --processes 4
+```
+
+The difference between `--workers` and `--processes` is that `--processes` will spawn worker processes immediately that will poll for tasks themselves. While --workers will maintain a queue of busy and idle workers and assign tasks to them, spawning processes as tasks are assigned.
+
+`--processes` is faster and will likely replace `--workers` in the future.
+
+When using `--processes`, the `--workers` parameter is automatically set to 0, so you don't need to specify it manually.
+
+### Limiting tasks per worker process
+
+You can specify a maximum number of tasks a self-selecting worker process should handle before it exits and gets respawned. This helps prevent memory leaks or resource issues in long-running worker processes.
+
+```sh
+manage.py fullctl_poll_tasks --processes 4 --max-tasks-per-process 100
+```
+
+Or using the short-form parameter:
+
+```sh
+manage.py fullctl_poll_tasks -p 4 -t 100
+```
+
+This will cause each worker process to automatically exit after processing 100 tasks, and a new worker process will be spawned to replace it. If not specified or set to 0, worker processes will continue running indefinitely.
+
+
+# Task tracking
+
+In `CommandInterface` there is a function `before_run` that runs before the command is run
+
+In the worker `Command` a separate thread is created to track the task processing to avoid blocking the main thread for the command worker
+
+The function of this thread is to update the TaskHeartbeart while the task is running
+
+This is done at intervals of the specified - env var `TASK_TRACK_INTERVAL_SECONDS`
+
+The `timestamp` field in the `TaskHeartbeat` model is used to check if the task is still running and not dead.
+
+This is always checked for all tasks when `/health` is visited