Consolidate sensor api #260
Conversation
| const ExternalUpstreamEntity = "ExternalResourceInterface" | ||
|
|
||
| // NewExternalOptimusManager creates a new instance of externalResourceResolver | ||
| func NewExternalOptimusManager(resourceManagerConfigs []config.ResourceManager) (*ExternalOptimusConnectors, error) { |
There was a problem hiding this comment.
can we reuse NewExternalUpstreamResolver on job BC?
we can provide interface specific to this use cases (GetJobScheduleInterval and GetJobRuns)
There was a problem hiding this comment.
Then we will be sending request to Job BC from Scheduler BC, even though when the Interface is diffrent.
what is your reason ?
There was a problem hiding this comment.
nvm, just want to minimize reimplementation of optimus manager constructor, since it's same with what we have in core/job/resolver/external_upstream_resolver.go, turns out it's used for different purpose, we're using same external manager that comes from package ext. not an issue
| return manager, nil | ||
| } | ||
| } | ||
| return nil, errors.NewError(errors.ErrNotFound, ExternalUpstreamEntity, "could not find external resource manager by host: "+hostURL) |
|
The current refactoring will not align with the change in approach for the windowing, as it will be a new api altogether. As a next step we will not have these many sensors, we will just have one sensor which will depend on data availability for all inputs combined. Should we implement this differently where job run gets the replay request for a given schedule, if the request has ignore upstreams we can ignore. |
Proton: goto/proton#120