lablink_allocator_service.routes.allocator_logs¶
lablink_allocator_service.routes.allocator_logs
¶
The allocator's own logs: a JSON tail plus the admin page that shows it.
Its own blueprint rather than part of admin_pages because this is the one
log source that comes off the local filesystem instead of the database --
start.sh writes it, since nothing mounts docker.sock and the allocator
therefore cannot run docker logs on itself.
Attributes¶
bp = Blueprint('allocator_logs', __name__)
module-attribute
¶
logger = logging.getLogger(__name__)
module-attribute
¶
Functions:¶
allocator_logs_api()
¶
Get the allocator's own logs.
Returns a redacted tail (last 2000 lines) of the allocator's own
container output, read from the file start.sh writes at
/var/log/lablink/allocator.log. Backs the /admin/allocator-logs
page. Values of PASSWORD/TOKEN/SECRET/KEY assignments are masked
before the response leaves the process.
Query Parameters:
errors_only(boolean, optional, defaultfalse): As onGET /api/vm-logs/<hostname>— reducesdocker_logsto its error lines.errorstill reports only a genuinely missing log file; a log with no error lines returnsdocker_logs: ""witherror: null.
Success Response:
- Code:
200 OK - Content:
The response mirrors /api/vm-logs/<hostname>'s keys so the shared logs
template's JavaScript works unchanged. cloud_init_logs is always
null: the allocator host's cloud-init output lives outside the
container and is out of scope. When no log file exists, docker_logs is
null and error explains why — the response is still 200.
Source code in packages/allocator/src/lablink_allocator_service/routes/allocator_logs.py
allocator_logs_page()
¶
Render the shared logs page pointed at this blueprint's API.