-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
package: Add support for different query job types: #452
Conversation
components/job-orchestration/job_orchestration/executor/query/fs_search_task.py
Show resolved
Hide resolved
components/job-orchestration/job_orchestration/scheduler/constants.py
Outdated
Show resolved
Hide resolved
@@ -124,6 +131,7 @@ def fetch_cancelling_search_jobs(db_conn) -> list: | |||
SELECT {QUERY_JOBS_TABLE_NAME}.id as job_id | |||
FROM {QUERY_JOBS_TABLE_NAME} | |||
WHERE {QUERY_JOBS_TABLE_NAME}.status={QueryJobStatus.CANCELLING} | |||
AND {QUERY_JOBS_TABLE_NAME}.type={QueryJobType.SEARCH} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assume we only cancel search job to simplify the implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The WebUI changes look good to me.
|
||
@abstractmethod | ||
def job_config(self) -> QueryConfig: ... | ||
|
||
|
||
class SearchJob(QueryJob): | ||
search_config: SearchConfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we rename this to just "job_config"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think search_config is fine.
@@ -124,6 +130,7 @@ def fetch_cancelling_search_jobs(db_conn) -> list: | |||
SELECT {QUERY_JOBS_TABLE_NAME}.id as job_id | |||
FROM {QUERY_JOBS_TABLE_NAME} | |||
WHERE {QUERY_JOBS_TABLE_NAME}.status={QueryJobStatus.CANCELLING} | |||
AND {QUERY_JOBS_TABLE_NAME}.type={QueryJobType.SEARCH} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the naming of QueryJobType.SEARCH
gets confusing for me here. When I see this my first thought is wondering about what happens to aggregation jobs, but actually QueryJobType.SEARCH
represents search AND aggregation jobs.
I think we might want to eventually split these out into different job types, but to avoid holding you up here how about we just rename this to QueryJobType.SEARCH_OR_AGGREGATION
which is ugly but more clear at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it also require renaming other places in the query_scheduler?
for example, "pending_query_job" will become "pending_query_or_aggregation_job", and "search_config" becomes "search_or_aggregation_config"?
I personally prefer to not rename those, but only change QueryJobType.SEARCH to QueryJobType.SEARCH_OR_AGGREGATION.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, let's just rename the SEARCH_OR_AGGREGATION and leave everything else. The aggregations are a query of sorts, so I think its fine.
|
||
@abstractmethod | ||
def job_config(self) -> QueryConfig: ... | ||
|
||
|
||
class SearchJob(QueryJob): | ||
search_config: SearchConfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think search_config is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small questions / suggestions.
components/job-orchestration/job_orchestration/scheduler/job_config.py
Outdated
Show resolved
Hide resolved
components/job-orchestration/job_orchestration/scheduler/scheduler_data.py
Outdated
Show resolved
Hide resolved
components/job-orchestration/job_orchestration/scheduler/scheduler_data.py
Outdated
Show resolved
Hide resolved
components/webui/imports/api/search/server/QueryJobsDbManager.js
Outdated
Show resolved
Hide resolved
components/job-orchestration/job_orchestration/scheduler/query/query_scheduler.py
Show resolved
Hide resolved
components/job-orchestration/job_orchestration/scheduler/query/query_scheduler.py
Outdated
Show resolved
Hide resolved
components/job-orchestration/job_orchestration/scheduler/query/query_scheduler.py
Outdated
Show resolved
Hide resolved
…/query_scheduler.py Co-authored-by: kirkrodrigues <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the PR title & body, how about:
package: Add support for different query job types:
- Add abstract classes for QueryJobType and QueryJobConfig.
- Submit and track job type in the search jobs table.
- Guard search-job specific handling in the scheduler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
- Add abstract classes for QueryJobType and QueryJobConfig. - Submit and track job type in the search jobs table. - Guard search-job specific handling in the scheduler.
Description
This PR is a preparation to let query-scheduler supports more than one type of jobs.
The following changes are made:
Validation performed
Built the package
Verified that search and reducer works properly from both commandline and webui