ferrosoft.container package¶
The ferrosoft.container package wires together the application’s
entry-point configuration: Django settings, URL routing, and error-tracking
initialisation.
This package is referenced by the DJANGO_SETTINGS_MODULE environment
variable that is baked into the production Dockerfile:
DJANGO_SETTINGS_MODULE=ferrosoft.container.settings
It is not an installable Django app — it contains no models, views, migrations, or management commands.
Modules¶
- settings
Bootstraps logging, Sentry, and delegates all Django settings population to
ferrosoft.config.load_django().- urls
Root URL dispatcher that mounts every installed application.
- sentry
Sentry SDK callbacks (
before_send_transactionfilters).
Submodules¶
ferrosoft.container.sentry module¶
Sentry SDK integration utilities for the Ferrosoft Platform.
This module provides before_send_transaction callbacks for use with
sentry_sdk.init(). These callbacks allow fine-grained control over
which performance traces are forwarded to Sentry, preventing high-traffic but
low-diagnostic-value endpoints from dominating the performance dashboard.
Note
filter_transactions() is also re-implemented inline inside
ferrosoft.container.settings for the production Sentry
initialisation. This standalone copy exists for independent unit testing
and potential reuse in other entry-points.
- ferrosoft.container.sentry.filter_transactions(event, hint)[source]¶
Drop Sentry transaction events for high-traffic, low-signal paths.
Intended to be passed as the
before_send_transactioncallback when callingsentry_sdk.init(). Discards transaction events whose request path is either the application root (/) or the login page (/accounts/login/). All other paths are forwarded to Sentry unchanged.The rationale for filtering these two paths is that they are hit constantly by health checks, redirects, and unauthenticated visitors, so recording a performance trace for every hit would produce noise that obscures genuine latency regressions in application paths.
- Parameters:
- Returns:
The unmodified
eventto forward it to Sentry, orNoneto discard it silently.- Return type:
dict | None
Example
Pass this function when initialising the Sentry SDK:
import sentry_sdk from ferrosoft.container.sentry import filter_transactions sentry_sdk.init( dsn="https://...", before_send_transaction=filter_transactions, )
ferrosoft.container.settings module¶
Django settings entry-point for the production container and CLI tools.
This module does not contain Django settings values directly. Instead it
bootstraps the runtime environment and then delegates all settings population
to ferrosoft.config.load_django(), which reads and merges one or more
YAML configuration files.
Boot sequence¶
BASE_DIRis resolved to the repository root — three directory levels above this file:container/→ferrosoft/→src/→ root.Noisy
paramikoSSH library deprecation warnings are suppressed; they surface in user-facing log output without containing actionable information.The root logging level is configured from the
FERROSOFT_LOG_LEVELenvironment variable (default"INFO").Sentry error tracking is initialised if
SENTRY_DSNis a non-empty string. Abefore_send_transactionfilter drops performance traces for the root path and the login page to avoid high-traffic noise in Sentry’s performance dashboard.ferrosoft.config.load_django()is called withglobals()to write every resolved YAML key into this module’s global namespace, making them available to Django as settings.
Environment variables¶
FERROSOFT_LOG_LEVELPython logging level name consumed by
logging.basicConfig()(e.g."DEBUG","WARNING"). Defaults to"INFO".SENTRY_DSNSentry Data Source Name. When empty or absent Sentry is not initialised and no data is sent to Sentry’s servers.
SENTRY_ENVIRONMENTSentry environment tag attached to every event (e.g.
"staging","production"). Defaults to"production".FERROSOFT_ENVActive configuration profile consumed by
ferrosoft.config.load_django(). Selects which top-level YAML key is merged on top of thedefaultblock. Defaults to"development".FERROSOFT_CONFIGColon-separated list of YAML configuration file paths consumed by
ferrosoft.config.load_django(). Files are merged left-to-right so later entries override earlier ones. Defaults to"settings.yml".
See also¶
ferrosoft.config: YAML-based settings loader and variable substitution.
ferrosoft.container.urls: Root URL configuration.
ferrosoft.container.urls module¶
Root URL configuration for the Ferrosoft Platform.
Django’s URL dispatcher resolves every incoming request against
urlpatterns. This module composes the top-level routing table by
delegating to each installed application’s own urls module.
URL layout¶
/ferrosoft.apps.ferrobase— Core platform views: tenant switcher, main dashboard, shared base pages, and the Prometheus metrics scrape endpoint (/metrics)./(two-factor)two_factor— Two-factor authentication views: login, TOTP/email setup wizard, backup token management, and QR code generator./admin/Django’s built-in admin site.
/api/ferrosoft.apps.webapi— Versioned REST API built with Django REST Framework. Includes all app-level DRF routers under a single prefix./api-auth/DRF’s browsable-API session login and logout views. Not used by API clients — only by the human-readable DRF interface during development.
/befundung/ferrosoft.apps.befundung— Examination request submission, status tracking, and assessment workflows./dataimport/ferrosoft.apps.dataimport— Bulk CSV/JSON data import pipeline, including WebSocket endpoints that stream import progress back to the browser./emiflow/ferrosoft.apps.emiflow— Emissions calculation, transport flow tracking, and emissions catalog management./reporting/ferrosoft.apps.reporting— Asynchronous report generation (PDF export) with WebSocket progress notifications./support/ferrosoft.apps.ticketing— Support ticket creation and management, backed by a Taiga project management integration.
Debug toolbar¶
Django Debug Toolbar URL patterns are appended to urlpatterns when
settings.DEBUG is True. Because DEBUG is always False in
production containers, the toolbar is never reachable in production.
Note
The ferrobase and two_factor URL includes both mount at the root
prefix ("") and together cover the unauthenticated entry-points
(login, token verification) as well as the post-login landing pages.
Order matters: ferrobase is listed first so that its paths take
precedence over the two-factor patterns where they overlap.