The query to find portfolios that are pending provisioning is updated to
check for:
- a period of performance that has started
- a portfolio state machine that has an UNSTARTED or one of the CREATED
states
I left several TODOs to ensure that the orchestration functions
correctly for portfolio.
Like claim_for_update, the claim_many_for_update claims resources with
an expiring lock. This was written to allow the updating of multiple
application roles with a single cloud_id, since multiple application
roles will map to a single Azure Active Directory user.
This adds:
- A Celery beat task for enqueuing application creation tasks
- A Celery task for creating the application
- Payload and Response dataclasses for creating management groups
It also does some incidental cleanup.
We don't know yet how useful the job failue tables will be, and
maintaining multiple failure tables--one for every entity involved in
CSP provisioning--is burdensome. This collapses them all into a single
table that track the entity type (environment, portfolio, etc.) and the
entity ID. That way we can construct queries when needed to find task
results.
AT-AT needs to be able to track which user tasks failed and why. To
accomplish this we:
- Enabled Celery's results backend, which logs task results to a data
store; a Postgres table, in our case.
(https://docs.celeryproject.org/en/latest/userguide/tasks.html#result-backends)
- Created tables to track the relationships between the relevant models
(Environment, EnvironmentRole) and their task failures.
- Added an `on_failure` hook that tasks can use. The hook will add
records to the job failure tables.
Now a resource like an `Environment` has access to it task failures
through the corresponding failure table.
Notes:
- It might prove useful to use a real foreign key to the Celery results
table eventually. I did not do it here because it requires that we
explicitly store the Celery results table schema as a migration and
add a model for it. In the current implementation, AT-AT can be
agnostic about where the results live.
- We store the task results indefinitely, so it is important to specify
tasks for which we do not care about the results (like `send_mail`)
via the `ignore_result` kwarg.
