refactor: Move ContainerExecutionStatus to enums module

[morgan-wowk]

Breaks the circular import that prevented event_listeners.py from typing
StatusTransitionEvent fields as ContainerExecutionStatus. All consumers
updated to import from the new enums module.

[morgan-wowk]

• feat: Add event_listeners module for event lifecycle support #203
• refactor: Move ContainerExecutionStatus to enums module #202 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[yuechao-qin]

nit: Would be better to be a bit descriptive for the name here like

• container_statuses
• models
• statuses

[morgan-wowk]

Do you suggest a folder instead?

enums
\_container_statuses.py

[yuechao-qin]

not a folder, just renaming the file. It's just that enums and enum (python's module) are so close, it's easy for my to confuse the two.

Mainly, it's probably good practice to describe the functionality of the file, not the technology. For example, if i named a file classes.py or functions.py, it'll be ambiguous.

[morgan-wowk]

Thanks. Changed

[Ark-kun]

>Breaks the circular import that prevented event_listeners.py from typing
StatusTransitionEvent fields as ContainerExecutionStatus.

Hmm. Let's solve this.

1. There should not be circular imports in this area
2. Circular imports are possible in Python

[Ark-kun]

From 1-1 discussion:
Let's have a simple solution like this:

• backend types remain unchanged
• orchestrator listens to status change events and adds them to history. Maybe, the status change handler will need to add a ExecutionNode._container_execution_status_changed = True mark. Telemetry is not involved here.
• telemetry listens to pre-commit and post-commit events. On pre-commit, it stashes the status change info it needs to send. On post-commit it sends out that info. Alternatively, we could just send the info in pre-commit hook. The chances of that transaction commit failing are close to 0.

[morgan-wowk]

From 1-1 discussion:
Let's have a simple solution like this:

• backend types remain unchanged
• orchestrator listens to status change events and adds them to history. Maybe, the status change handler will need to add a ExecutionNode._container_execution_status_changed = True mark. Telemetry is not involved here.
• telemetry listens to pre-commit and post-commit events. On pre-commit, it stashes the status change info it needs to send. On post-commit it sends out that info. Alternatively, we could just send the info in pre-commit hook. The chances of that transaction commit failing are close to 0.

​Thanks! That was a good dicussion. Cleaner solution coming soon!