Skip to content

README.md

Latest commit

 

History

History
186 lines (150 loc) · 11.9 KB

README.md

File metadata and controls

186 lines (150 loc) · 11.9 KB

Resource Locker project

This project is a Back-end service with API endpoints and web UI, for monitoring the resources created in different cloud providers, define their usage availability by locking/unlocking a resource.

Project Dependencies:

  • rlockerservices - Services repository that the rlocker uses
  • rlockertools - A Python based client interface to interact with the platform

Quick Start Video will be added soon

Project Architecture:

Django website with applications, account, api, dashboard, health, lockable_resource, rqueue

  • account: Designed to add more functionalities to the built-in user app

    • management: Directory that includes other python files that could be used as python manage.py name_of_file
    • __ init __: Packaging this account directory (Django App)
    • apps: Application configurations
    • signals: A signal to create a Token object so each Account will have an associated Token
    • urls: Urls that are related to the Account, like user login
    • views: Views that are related to auth actions like login and logout (We do not enable registration from the WEB UI)

  • admin_tools: Designed to add more administrative actions, such as importing and exporting the current status of lockable resources

    • __ init __: Packaging this account directory (Django App)
    • apps: Application configurations
    • urls: Urls that are related to the Admin tools
    • views: Views in order to display the different administrative tools

  • api: Application Programming Interface in order to automate resource locking releasing via endpoints.

    • __ init __: Packaging this account directory (Django App)
    • apps: Application configurations
    • custom_permissions: For enabling only access for non anonymous users, a permission mechanism should be written in api application
    • serializers: Serializers Object for the api, to prepare JSON responses.
    • urls: Endpoints that are enabled after the api prefix
    • utils: Useful functions for the api application
    • views: Views where we will take actions in each endpoint, depending on the request method.

  • dashboard: Designed to display a read-only dashboard for more centralized view of the lockable resources with more details

    • __ init __: Packaging this account directory (Django App)
    • apps: Application configurations
    • urls: Endpoints that are enabled for this application
    • views: Views where we will manipulate the data we'd like to display in the dashboard

  • health: Designed to have a health check URL that returns a raw string, so it will be easier to check health of the entire platform

    • __ init __: Packaging this account directory (Django App)
    • apps: Application configurations
    • urls: URL endpoints of this specific application
    • views: Views of this specific application

  • lockable_resource: Application Programming Interface in order to automate resource locking releasing via endpoints.

    • __ init __: Packaging this account directory (Django App)
    • management: Directory that includes other python files that could be used as python manage.py name_of_file
    • action_manager: Includes all the classes that are doing some action on the lockable resource
    • admin: Model Registrations to the admin panel of the Django Application
    • apps: Application configurations
    • constants: Constants of the lockable resource app, we define there rules for available status types that a lockable resource object can have
    • exceptions: We define in the exceptions the actions that are not making sense, for i.e locking a resource that is already locked
    • label_manager: Takes responsibility to perform smart retrieving of an available resource by only specifying it's label
    • query_param_manager: Includes functions for handling query params in the lockable resource page (for i.e: ?view_as=yaml)
    • models: Modelize a schema of the table for different Lockable resources we will manage.
    • signals: Signals to be triggered once a specific field of lockable resource object changes
    • urls: Available URL's from the Web UI to manage the lockable resources
    • views: Design of the views and actions to take in GET/POST requests.

  • rqueue: Application for managing the requests that could not be locked immediately, this is a queue management system application

    • __ init __: Packaging this account directory (Django App)
    • admin: Model Registrations to the admin panel of the Django Application
    • apps: Application configurations
    • constants: Constants of the rqueue app, we define there priority enumerations, time intervals for resource availability check
    • context_processors: Since we want some data to be accessible from each HTML template, we have to define it as a global context that is available (from settings.py)
    • models: Modelize a schema of the table for different requests in queue
    • signals: Signals to be triggered once a rqueue object is being created.
    • urls: Available URL's from the Web UI to manage the requests in queue
    • utils: Helper functions for the rqueue applications. for i.e - displaying nicer string for the pended time of a queue
    • views: Design of the views and actions to take in GET/POST requests.

How to use Addons (Plugins) in the Resource Locker Project (To be documented)

Dev mode:

  • The following are commands to run in your terminal, each line represents a pattern of: command to run Explanation
    • git clone https://github.com/red-hat-storage/rlocker.git Clones the project
    • cd rlocker Change directory
    • python --version Python3.8 or above is required, please double-check this with that command
    • python -m venv venv Create a virtual environment for the django app
    • The following command differs from Windows to Linux systems:
      • venv\Scripts\activate Run this to activate the venv on Windows
      • source venv/bin/activate Run this to activate the venv on Linux
    • pip install -r requirements.txt Install the required packages
      • Expected errors on the command above:
    • The following commands are environment variable setups. The command to set an env variable is export (PLEASE USE SET AND NOT EXPORT IN WINDOWS!)
      • Visit the following website in order to generate a secret key for our Django application: link
        • Click the Generate button to generate a DJANGO_SECRET. Now the secret key is copied to your clipboard (Could be pasted the next time you send a Ctrl+V)
        • export DJANGO_SECRET='<YOUR_COPIED_SECRET>' Set this env variable. The wrapping with single quotes is important!
        • export USE_DEV_DB=True Here we specify to use the local db.sqlite3 file and not a PostgreSQL database engine (That is why, we could skip the psycopg2-binary package in previous steps)
        • export DEBUG=True Debug mode on.
        • export CSRF_TRUSTED_ORIGINS='http://localhost:8000' (Optional for dev) CSRF trusted origins. For local development, use localhost.
    • Launch the website on the desired port (default is 8000)
      • python manage.py runserver <OPTIONAL_PORT> As said above, you do NOT HAVE to mention the <OPTIONAL_PORT>
    • Login Credentials are: admin, Admin-1
  • Next Steps:
    • Visit the rlockerservices project in order to setup the queue_service. The queue service is the component that processes the queues that are coming from rlocker-cli.

Production

Required Environment Variables

When deploying to production (e.g., OpenShift), the following environment variables must be configured:

Required:

  • DJANGO_SECRET - Django secret key for cryptographic signing. Generate using djecrety.ir
  • POSTGRESQL_DATABASE - PostgreSQL database name
  • POSTGRESQL_USER - PostgreSQL username
  • POSTGRESQL_PASSWORD - PostgreSQL password
  • DATABASE_SERVICE_NAME - PostgreSQL host/service name
  • CSRF_TRUSTED_ORIGINS - Comma-separated list of trusted origins for CSRF validation (Required for Django 5.0+)
    • Example: https://rlocker.apps.example.com,https://rlocker-dev.apps.example.com
    • Important: Must match your application's route URL(s) with the https:// protocol

Optional:

  • DEBUG - Set to True for debug mode (should be False in production)
  • USE_DEV_DB - Set to True to use SQLite instead of PostgreSQL (not recommended for production)
  • USE_DEV_ADDONS - Set to True to use development addons

Proxy Configuration

The application is configured to work behind reverse proxies (nginx, OpenShift router, etc.):

  • SECURE_PROXY_SSL_HEADER is set to trust the X-Forwarded-Proto header
  • This allows Django to correctly identify HTTPS connections when behind a reverse proxy

OpenShift Deployment

To set environment variables in OpenShift:

# Get your route URL
oc get routes

# Set CSRF trusted origins (replace with your actual route)
oc set env deployment/<deployment-name> CSRF_TRUSTED_ORIGINS="https://your-app-route.apps.example.com"

# Set other required environment variables
oc set env deployment/<deployment-name> \
  DJANGO_SECRET="<your-secret-key>" \
  POSTGRESQL_DATABASE="<db-name>" \
  POSTGRESQL_USER="<db-user>" \
  POSTGRESQL_PASSWORD="<db-password>" \
  DATABASE_SERVICE_NAME="<db-service-name>"

Alternatively, set environment variables via the OpenShift Web Console under Deployment → Environment tab.

Database Maintenance

Queue Cleanup

The rqueue_rqueue table accumulates completed queue records over time. To prevent database bloat, use the cleanup management command:

# Manual cleanup - delete records older than 30 days
python manage.py cleanup_old_queues --days=30

# Dry run to preview what would be deleted
python manage.py cleanup_old_queues --days=30 --dry-run

# Different retention by status
python manage.py cleanup_old_queues \
  --finished-days=30 \
  --aborted-days=60 \
  --failed-days=90

For automated cleanup in OpenShift, deploy the provided CronJob:

# Edit openshift/cronjob-cleanup-queues.yaml to match your configuration
# Then deploy:
oc apply -f openshift/cronjob-cleanup-queues.yaml

# Monitor the CronJob
oc get cronjobs
oc get jobs

See docs/QUEUE_CLEANUP.md for detailed documentation.