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

Don't queue EmsRefresh if using streaming refresh #17531

Merged

Conversation

agrare
Copy link
Member

@agrare agrare commented Jun 6, 2018

If a target's ems is using streaming refresh don't queue an EmsRefresh
because it will not be processed.

VMware associated PR: ManageIQ/manageiq-providers-vmware#284

@agrare
Copy link
Member Author

agrare commented Jun 12, 2018

Hey @Fryguy one of the things that we still need to handle with streaming refresh is what to do about places that queue standard EmsRefresh.refresh actions.

This will prevent new refreshes from being queued (e.g. all of the automate event handlers) and ManageIQ/manageiq-providers-vmware#284 will prevent existing queued refresh messages from being delivered.

WDYT?

@@ -51,6 +51,9 @@ def self.queue_refresh(target, id = nil, opts = {})
h[e] << t unless e.nil?
end

# Drop targets on EMSs which are using streaming refresh
targets_by_ems.reject! { |ems, _| ems.supports_streaming_refresh? }
Copy link
Member

Choose a reason for hiding this comment

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

Some providers support it, but don't "currently" support it because of a setting flag...does this method handle that case?

Copy link
Member Author

@agrare agrare Jun 26, 2018

Choose a reason for hiding this comment

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

Yes we're checking the settings for if it is enabled not just if it is supported here

@Fryguy
Copy link
Member

Fryguy commented Jun 25, 2018

Just looked at the other PR: I would be wary about the support_* prefix because that is "reserved" by the supports_feature thing. But on that note, maybe this should be a supports_feature thing directly. That way, you can handle that "supports refresh but not right now" case.

@agrare
Copy link
Member Author

agrare commented Jun 26, 2018

Yeah you're right I'll change it to use supports_feature.

@agrare agrare force-pushed the dont_queue_refreshes_for_streaming_refresh branch 3 times, most recently from 9b2e8af to bf660b6 Compare June 26, 2018 13:24
@agrare
Copy link
Member Author

agrare commented Jun 26, 2018

@Fryguy okay updated

@agrare agrare force-pushed the dont_queue_refreshes_for_streaming_refresh branch 5 times, most recently from 96f2be9 to f1aa6ba Compare July 2, 2018 20:30
@Fryguy
Copy link
Member

Fryguy commented Jul 9, 2018

Where is the default defined? Or is that part of support feature itself?

@agrare
Copy link
Member Author

agrare commented Jul 9, 2018

@agrare agrare force-pushed the dont_queue_refreshes_for_streaming_refresh branch from f1aa6ba to 0a740a4 Compare July 10, 2018 17:36
Copy link
Contributor

@Ladas Ladas left a comment

Choose a reason for hiding this comment

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

If a target's ems is using streaming refresh don't queue an EmsRefresh
because it will not be processed.
@agrare agrare force-pushed the dont_queue_refreshes_for_streaming_refresh branch from 0a740a4 to 946bd7f Compare August 15, 2018 19:18
@miq-bot
Copy link
Member

miq-bot commented Aug 15, 2018

Checked commit agrare@946bd7f with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
3 files checked, 0 offenses detected
Everything looks fine. 🏆

@Fryguy Fryguy merged commit bc2104e into ManageIQ:master Aug 16, 2018
@Fryguy Fryguy added this to the Sprint 93 Ending Aug 27, 2018 milestone Aug 16, 2018
@agrare agrare deleted the dont_queue_refreshes_for_streaming_refresh branch August 16, 2018 18:13
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.

4 participants