-
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
Tower CUD check and run refresh_in_provider followed by refreshing manager #15025
Conversation
@jameswnl Cannot apply the following label because they are not recognized: fine/yess |
@miq-bot add_labels fine/yes |
Checked commit jameswnl@ee90bbf with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
@Ladas, can you take a look at the graph refresh flow? Need to make sure that if a targeted refresh is requested, but not implemented, then the full refresh is kicked off instead. Can be done as a separate follow-up PR. But, I don't think the callers should care if the targeted refresh exists for specific objects yet. The callers should be able to assume it can call a refresh with a target and the target gets refreshed (even if it means it's a full refresh). |
@blomquisg right, we need to redesign the target refresh queuing, this queues the AR object, so it will be filtered out by the core code. @durandom ^ |
Tower CUD check and run refresh_in_provider followed by refreshing manager (cherry picked from commit 2b14633) https://bugzilla.redhat.com/show_bug.cgi?id=1448098
Fine backport details:
|
The targeted refresh is only implemented on
confirguration_script_source
and so if it is in the context of updating acredential
, therefresh
on thecredential
will be dropped.In prior PR, was convinced by this section that it will fall back to ems refresh automatically.
Now realized, it will be dropped by this queue attempt way before.
@miq-bot add_labels fine/yess, providers/ansible_tower, blocker, bug