Skip to content

Conversation

@michael-johnston
Copy link
Member

@michael-johnston michael-johnston commented Nov 18, 2025

This PR:

  • Removes orchestrate.orchestrate_operation_function and _orchestrate_explore_operation.orchestrate_explore_operation_function_wrapper
    • By unifying the parameters/return types of general/explore orchestrate functions along with run_operation_harness
  • Enables general operators to receive a ray namespace to create actors etc. in (if required)
  • Simplifies retrieving actuator configurations for general operations
  • The orchestrate*operation functions now set ray namespace

Towards fixing #200 where we need to be able to isolate each operation. It will be easier if the orchestrate_*_operation functions contain same information, control same orchestration elements, and there are no extraneous functions to have to deal with.

The refactoring moves general/explore orchestration function to private modules for clarity.

However we don't want to expose this private modules external - want to keep the access point orchestrate.py
orchestrate_explore_operation
…operation

# Conflicts:
#	.secrets.baseline
#	orchestrator/modules/operators/orchestrate.py
…operation

# Conflicts:
#	orchestrator/modules/operators/orchestrate.py
Remove unused parameters.
Not needed as its we must use the one given by discover_space.project_context
from orchestrate and orchestrate_exploer_operation.

it was never not None so not required to be a parameter
Originally required as it held common function for two sub-classes.
However, one of those was removed meaning we don't need a base class anymore and can simplify the code
From orchestrate to general_orchestration.
This is because
- orchestrate_explore_operation already does this so it doesn't need it from orchestrate
- the information is not passed from orchestrate to orchestrate_general_operation
- orchestrate_general_operation should have this info but it needs to acquire it itself in case the function is called directly (not via orchestrate)

Hence, it's redundant to have this code here. The correct place its needed is in orchestrate_general_operation
@DRL-NextGen
Copy link
Member

DRL-NextGen commented Nov 18, 2025

Checks Summary

Last run: 2025-11-21T17:17:01.590Z

Code Risk Analyzer vulnerability scan found 2 vulnerabilities:

Severity Identifier Package Details Fix
🔷Medium CVE-2025-50181 urllib3
urllib3 redirects are not disabled when retries are disabled on PoolManager instantiationGHSA-pq67-6m6q-mj2v

urllib3:2.3.0->kubernetes:34.1.0
2.5.0
🔷Medium CVE-2025-50182 urllib3
urllib3 does not control redirects in browsers and Node.jsGHSA-48p4-8xcf-vxj5

urllib3:2.3.0->kubernetes:34.1.0
2.5.0

Extract functions for getting and validating actuator configurations. Rename methods.

The reason is that as-is simplified get/validate is tied to DiscoveryOperationResourceConfiguration but this constrains where it has to happen to the existence of an instance of the class.
now takes more basic components and is called create_operation_and_add_to_metastore
Update parameters to take operator module/parameters/info rather than having them bundled in DiscoveryOperationConfiguration instance

Update to new create_operation_and_add_to_metastore interface.
michael-johnston and others added 8 commits November 21, 2025 15:37
Update parameters to take operator module/parameters/info rather than a DiscoveryOperationResourceConfiguration instance.

This is so the parameters are as similar as possible to orchestrate_general_operation make the paths to each more unififed.

Remove namespace parameter = the orchestrate function will generate its own namespace for its operation

Simplify return to OperationOutput - other instance returned are deducible from this or were input

Remove orchestrate_operation_function_wrapper - no longer necessary due to change in orchestrate_explore_operation input/output
Change parameters to take operator_module and parameters instead of requiring them to be bundled in DiscoveryOperationResourceConfiguration
To allow communicating it to a general operation that wants to create ray actors/remotes
No need to call wrapper or set namespace explicitly.
Also update to new run_operation_harness
- Don't namespace at orchestrate level, let the orchestration functions set namespace
- Update to new orchestrate_*_operation interfaces
- Remove orchestrate_operation_function - no longer necessary
@michael-johnston michael-johnston changed the title fix: operation in operation refactor: orchestrate Nov 21, 2025
@michael-johnston michael-johnston marked this pull request as ready for review November 21, 2025 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants