Skip to content
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

Suspend providers #17452

Merged
merged 14 commits into from
Dec 18, 2018
Merged

Suspend providers #17452

merged 14 commits into from
Dec 18, 2018

Conversation

slemrmartin
Copy link
Contributor

@slemrmartin slemrmartin commented May 21, 2018

@miq-bot miq-bot added the wip label May 21, 2018
app/models/miq_queue.rb Outdated Show resolved Hide resolved
@@ -206,6 +209,20 @@ def self.submit_job(options)
put(options)
end

# TODO: Array param not seen yet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@agrare this can be list of any <models_class, id>, right? I wonder if we need to check enabled for each. There might be a better place for it (where the array resources are loaded from the DB)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ladas yeah we do that lookup here so maybe you could retry it later here?

if resource.respond_to?(:ext_management_system)
ems = resource.ext_management_system
if ems.present? && !ems.enabled
_log.info("Provider is disabled: #{ems.name}. MiqQueue skipped.")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably log the options too? And we can probably make it log.debug

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already a method for logging all the queue options properly, so use that one.

@@ -177,6 +177,15 @@ def hostname_format_valid?

default_value_for :enabled, true

def self.enable(ems_id)
ExtManagementSystem.where('id = ? OR parent_ems_id = ?', ems_id, ems_id).update_all(enabled: true)
Copy link
Member

@Fryguy Fryguy May 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer where(:id => ems_id).or.where(:parent_ems_id => ems_id)

Also, you can leave out the model name just start the line with where(:id => ...

@Fryguy
Copy link
Member

Fryguy commented May 24, 2018

@jrafanie Please review.

Personally, I'm reacting negatively to modifying any of the queueing code for when a worker is disabled. It feels like the wrong place. I understand how you are trying to avoid filling up the queue when a worker is disabled, but it feels like a sledgehammer approach because there may be things that do have to get to the queue. However, I'm not sure how to solve it directly, otherwise I'd offer an suggestion. :)

@slemrmartin
Copy link
Contributor Author

@Fryguy This is the reason when I make PR in too incomplete state, because I feel it could have side effects. So I'll try to find better places.
I have some starting point where metrics collection starts,
and beginning of smart state process (which is really nice to debug..generic worker -> queue -> generic worker -> queue -> generic worker -> queue.....etc.)
It would be great if someone more experienced tell me more

@Ladas
Copy link
Contributor

Ladas commented May 24, 2018

@Fryguy so question is, what things do have to get to the queue? :-)

I am thinking e.g. retirement? Is that queued by scheduler? Then it has to be somehow postponed, until the provider is started again. Then e.g. metrics collection should be just cancelled (both collection and processing).

If this will not be solved in a generic place, we will need to get a list of tasks we should not queue/cancel/postpone. And this should be probably documented, because there are side effects. (e.g. retirement can be postponed -> cost will be bigger than expected, metrics collection might have a data gap -> charge-back and reports will not be accurate, etc.)

@@ -173,6 +173,9 @@ def self.put(options)
def self.submit_job(options)
service = options.delete(:service) || "generic"
resource = options.delete(:affinity)

return unless resource_enabled?(resource)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused, what about places that do MiqQueue.put or other callers of .put? Why is submit_job singled out here? I'd think we'd need it everywhere we put something on the queue.

@slemrmartin slemrmartin mentioned this pull request May 29, 2018
13 tasks
@slemrmartin slemrmartin changed the title [WIP] Suspend provider's workers Suspend provider's workers May 29, 2018
@miq-bot miq-bot removed the wip label May 29, 2018
@slemrmartin slemrmartin changed the title Suspend provider's workers [WIP] Suspend provider's workers May 29, 2018
@miq-bot miq-bot added the wip label May 29, 2018
@slemrmartin slemrmartin changed the title [WIP] Suspend provider's workers Suspend provider's workers May 30, 2018
@slemrmartin
Copy link
Contributor Author

Please review.
I'm not sure if travis is failing due to this PR, my local branch is fine and test doesn't seem to be related to this PR

# - these workers are not provider specific, but provider-type specific
# @param value [Boolean]
def change_enabled_with_children!(value)
self.enabled = value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this is better to handle as an after hook such that after enabled= is modified, then we push down to the children. That way the caller just calls enabled=, then .save!

def enable!
_log.info("Enabling EMS [#{name}] id [#{id}].")
update!(:enabled => true)
end

This comment was marked as outdated.

@slemrmartin slemrmartin changed the title Suspend provider's workers [WIP] Suspend provider's workers Jun 18, 2018
@slemrmartin slemrmartin changed the title [WIP] Suspend provider's workers [WIP] Suspend providers Jun 18, 2018
@miq-bot miq-bot added the wip label Jun 18, 2018
@bdunne
Copy link
Member

bdunne commented Nov 16, 2018

Have we tested other repos (UI & API repos in particular) with these changes? I wouldn't be surprised if this breaks some tests.

@Ladas
Copy link
Contributor

Ladas commented Nov 19, 2018

@bdunne @agrare asking for

MiqRegion.seed
Zone.seed

in every spec doesn't make any sense. We should have appliance_setup / server_setup spec helper, that is shared among all specs (in all repos) and calls these things on 1 place. And we shouldn't ask for refactoring like this in a customer issue, there needs to be separate PR for this.

This PR needs to get backported, so it would be best not to change every repo out there. (and AFAIK, we're not backporting cleanups)

@slemrmartin
Copy link
Contributor Author

slemrmartin commented Nov 22, 2018

tested on 14 repos, number of failures decreased to 3, which are solved by ManageIQ/manageiq-providers-ovirt#311 (has to be merged first)

@miq-bot
Copy link
Member

miq-bot commented Dec 12, 2018

This pull request is not mergeable. Please rebase and repush.

@miq-bot
Copy link
Member

miq-bot commented Dec 13, 2018

Checked commits slemrmartin/manageiq@352ddb4~...1bd6e0e with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
16 files checked, 4 offenses detected

app/models/zone.rb

spec/models/miq_queue_spec.rb

@jrafanie jrafanie merged commit 5f5b04b into ManageIQ:master Dec 18, 2018
@jrafanie jrafanie added this to the Sprint 101 Ending Dec 17, 2018 milestone Dec 18, 2018
@slemrmartin slemrmartin deleted the suspend-workers branch January 24, 2019 08:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants