-
Notifications
You must be signed in to change notification settings - Fork 897
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
JobProxyDispatcher should use all container image classes #15519
JobProxyDispatcher should use all container image classes #15519
Conversation
@moolitayer please review @miq-bot add_label bug |
This changes |
889af09
to
681ff98
Compare
app/models/job_proxy_dispatcher.rb
Outdated
@@ -193,12 +195,11 @@ def self.waiting? | |||
end | |||
|
|||
def pending_jobs(target_class = VmOrTemplate) | |||
class_name = target_class.base_class.name |
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.
any idea what was the result of this line?
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 both ContainerImage
and VmOrTemplate
the result was their class name ("ContainerImage", "VmOrTemplate" as strings).
#15519 (comment)
@@ -174,6 +174,7 @@ | |||
end | |||
|
|||
context "with container and vms jobs" do | |||
let (:container_image_classes) { ContainerImage.descendants.collect(&:name).append('ContainerImage') } |
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.
please test for a list as well
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.
@jrafanie can you please review this change? |
app/models/job_proxy_dispatcher.rb
Outdated
@@ -1,5 +1,7 @@ | |||
class JobProxyDispatcher | |||
include Vmdb::Logging | |||
|
|||
CONTAINER_IMAGE_CLASSES = ContainerImage.descendants.append(ContainerImage) |
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 don't think its safe to do this once in require time, please move to a method
681ff98
to
68a2271
Compare
68a2271
to
c8a16c6
Compare
app/models/job_proxy_dispatcher.rb
Outdated
@@ -93,6 +94,10 @@ def dispatch | |||
_log.info "Complete - Timings: #{t.inspect}" | |||
end | |||
|
|||
def container_image_classes | |||
ContainerImage.descendants.append(ContainerImage) |
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 know the current pattern does this but it feels like the dispatcher shouldn't have this knowledge. Additionally, it would cause us to load each of these classes and any requires they do in the schedule worker... a process that probably shouldn't load container dependencies. I'm not sure of a better solution but if you have an idea, do let us know.
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.
- We can check for jobs with target != VmOrTemplate.
It is a hack, maybe if we add a comment that states that if we ever get a target that isn't one of the two we should rethink. - Maybe we can look at job.type instead
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.
hi @moolitayer, thanks... One thing that still confuses me is it feels like the vm scans are really VmOrTemplateScanJob things (hiding as the Job class) and the container image scans are really ContainerImageScanJob things (hiding as a list of descendent classes + self here)... I don't know why we didn't use single table inheritance on this table in the past but I'm wondering if we should do it now. Perhaps fix this without a migration like you are here for any backports... but then, fix it right on master with STI. What do you think? cc @Fryguy
The nice thing is then you can do ContainerImageScanJob.where... or VmOrTemplateScanJob.where as you would expect. This might break the UI in many places where they're expecting Job classes by name, but it feels like we're doing it the hard way and fixing this might help maintenance in the future.
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.
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 don't know why we didn't use single table inheritance on this table in the past but I'm wondering if we should do it now.
We already do have STI on the jobs table.
I added a commit to use the Job table STI instead of searching by the target class. @jrafanie @gtanzillo can you take a look? |
Checked commits enoodle/manageiq@c8a16c6~...3bbab0d with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 spec/models/job_proxy_dispatcher_spec.rb
|
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 👍
state != 'finished' and | ||
(zone is null or zone = ?) and | ||
sync_key is not NULL)", @zone) | ||
job_class.order(:id) |
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.
@hsong-rh Please review the change here to use VmScan
by default to look up Job
objects instead of using Job.where(:target_class => "VmOrTemplate")
. Looks good to me but I want to confirm with you.
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.
ping @hsong-rh ?
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, just waiting for approval from the SSA team.
@enoodle @moolitayer @jrafanie any consideration on the Jobs already present in the db? Should we be concerned about those? (When/if they'll fail will they just disappear or will they remain in the db forever?) |
We are changing here the way that we locate the Jobs, Instead of locating jobs by the target class we are locating them by the class of the job. "old" jobs would still be found by this so I don't see it creating any problems. |
That is my understanding as well |
cc @Loicavenel |
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.
Looks good to me.
With the addition of new container image classes in ManageIQ/manageiq-providers-openshift#23 the JobProxyDispatcher should now address all of them.
This changes the way that Jobs are identified by the dispatcher so that they will be found by the type of job instead of the job's target class.