-
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 to invoke targeted refresh #14954
Conversation
@miq-bot remove_label wip |
0377e18
to
8f2e0cd
Compare
78dfd3f
to
eaa0422
Compare
@@ -8,7 +8,9 @@ def create_in_provider(manager_id, params) | |||
tower_object = provider_collection(manager).create!(params) | |||
|
|||
refresh(manager) | |||
find_by!(:manager_id => manager.id, :manager_ref => tower_object.id) | |||
target = find_by!(:manager_id => manager.id, :manager_ref => tower_object.id) | |||
refresh(target) |
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.
Event-base has to perform a 2nd refresh as well -- except if we don't need to return the db record here.
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 must be missing something but why would we need to refresh the target again if we just refreshed the whole manager?
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 target refresh of a project would trigger Tower side repo sync first. Ems refresh will not.
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.
Agreed, once you've refreshed the manager, the target must exist.
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'll try to fill in the details from what I know.
"We" want to make sure that the Tower Repos have done a git pull
before we refresh them. This allows the inventory collection to get the most up-to-date playbooks from the repos.
However, this is only implemented for targeted refreshes. This means that while doing a targeted refresh of a Tower Repo, the refresh process will ask the repo to update (git pull
), and waits until it knows that's done. Then, it continue with the targeted refresh.
This is not done for full refreshes. I guess, because it would mean that the full refresh would have to ask all of the repos to git pull
and maybe it's too hard correlating all those events back together to mean "all repos are updated, continue full refresh".
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.
To me this looks like a combination of refresh_new_target
(the oVirt event-based refresh stuff I talked about earlier) and native operation workflow
.
Talked to @agrare a little offline and sounds like we're in agreement.
The trick here is that this change is blocking the final Fine build scheduled for next week. And, I'm not sure there's going to be time to change this all around to try to use any of that.
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 if this is what we have to do to fix a blocker I'm 👍 with it
Longer term I agree refresh_new_target and native op workflow can help here; I think we should also look at the inconsistent behavior between manager/full refresh and targeted refresh.
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 we should also look at the inconsistent behavior between manager/full refresh and targeted refresh.
Yeah, big 👍 here.
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.
See my latest patch. It is now 1 refresh.
@@ -6,7 +6,9 @@ def create_in_provider(manager_id, params) | |||
params = provider_params(params) if respond_to?(:provider_params) | |||
manager = ExtManagementSystem.find(manager_id) | |||
tower_object = provider_collection(manager).create!(params) | |||
|
|||
if respond_to?(:refresh_in_provider) |
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.
here we already have the tower object and so we can try to trigger the sync.
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 like this better ... The full refresh can stay for now until we have @agrare's refresh_new_target
in place.
And, this avoids doing the double refresh just to make sure we get the updated Tower git repo.
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.
Nice @jameswnl this looks much better :)
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.
dont want to be the spoilsport, but refresh_new_target
is for the old refresh and this is using the graph refresh.
But good news follows: afaik the graph refresh supports that out of the box. ManagerRefresh::Target
@Ladas can you point to a small code sample in amazon, where you create objects from hashes?
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 we can integrate that to the refresh_new_target and switch based on configuration.
5437da9
to
d584c35
Compare
@@ -81,7 +82,7 @@ def update_in_provider_queue(params) | |||
|
|||
def delete_in_provider | |||
with_provider_object(&:destroy!) | |||
self.class.send('refresh', manager) | |||
self.class.send('refresh', self) |
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 delete
should still be a full refresh, right? I don't know if deletes can be targeted since it might have to be removed from other relationships.
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.
that's true!
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.
done
d584c35
to
bd16336
Compare
@@ -4,7 +4,7 @@ def connection | |||
end | |||
|
|||
def projects | |||
target.refresh_in_provider | |||
target.class.refresh_in_provider(project) |
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 hate being a jerk about this, but I think the instance method should remain, even if there needs to be a class method available for calling refresh_in_provider
on objects not yet in the MIQ DB.
I would see it as:
module Shared::ConfigurationScriptSource
module ClassMethods
def refresh_in_provider(project)
# ... full impl
end
end
def refresh_in_provider
with_provider_object { |project| self.class.refresh_in_provider(project) }
end
end
Then, callers don't need to do all the class
dereferencing on instances and then have to know that they need to get the underlying provider project reference to pass into the class method.
And, then this line would just revert to the original source.
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.
This is nice. Done now!
bd16336
to
c051b3a
Compare
I think I outlined this here https://www.pivotaltracker.com/story/show/144430761 quite good. |
@durandom yup that's exactly it :) Also sorry for the close/reopen...its right next to the comment button haha |
Dang @agrare! Throwin' down the gauntlet! |
c051b3a
to
e623e7f
Compare
Checked commit jameswnl@e623e7f with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
@miq-bot add_label fine/yes |
Fine backport details:
|
Tower CUD to invoke targeted refresh (cherry picked from commit edd5c1b) https://bugzilla.redhat.com/show_bug.cgi?id=1448098
For bug https://bugzilla.redhat.com/show_bug.cgi?id=1445995
After adding/editing a repo, user would like to see the playbooks asap. This PR is to trigger Tower's internal repo sync and we'll then inventory the updated repo and its playbooks.
@miq-bot add_label bug, providers/ansible_tower, wip