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

[WIP] Add ServiceAnsiblePlaybook.check_connection #20645

Closed

Conversation

NickLaMuro
Copy link
Member

@NickLaMuro NickLaMuro commented Oct 2, 2020

Allows a ServiceAnsiblePlaybook instance to check the remote endpoint for a repo to see if it can connect prior to attempting a clone.

This PR also creates some internals in GitRepository and GitWorktree to facilitate this and call into the rugged/libgit2 internals (all sharing the same method name: .check_connection)

Links

Steps for Testing/QA

I tested this by running it in a jansa VM with this patch applied:

  1. From a jansa appliance UI, , and create + run a playbook service
  2. SSH into the vm, apply the changes, and test in a rails console:
$ ssh root@[MIQ_VM]
root@MIQ_VM # vmdb
root@MIQ_VM # git init
root@MIQ_VM # git apply <(curl -L https://github.com/ManageIQ/manageiq/pull/20645.patch)
root@MIQ_VM # bin/rails c
irb> ServiceAnsiblePlaybook.first.check_connection(:provision)
#=> true

This method takes a `url` and uses that to create an anonymous remote to
use the `rugged`/`libgit2` to check the connection of a given remote.
Will make use of any credentials that are configured for the worktree.
For a given repository record, check the connection for the configured
url.

In this case, an existing repository is not used or created, and simply
a "stub repository" is created in a tmpdir to allow calling
`check_connection` with the configured url for the repo record.
Allows calling `.check_connection` from a given `ServiceAnsiblePlaybook`
instance.

A new `.repository` method was created to allow fetching the
`GitRepository` record and calling `GitRepository#check_connection`
from the `ServiceAnsiblePlaybook`.
@NickLaMuro
Copy link
Member Author

@tinaafitz @d-m-u Hopefully this helps with the BZ you are working on.

@miq-bot
Copy link
Member

miq-bot commented Oct 2, 2020

Checked commits NickLaMuro/manageiq@f65b139~...ff7eb86 with ruby 2.6.3, rubocop 0.69.0, haml-lint 0.28.0, and yamllint
4 files checked, 0 offenses detected
Everything looks fine. ⭐

@tinaafitz
Copy link
Member

Thanks so much @NickLaMuro. We'll start testing the changes.

Copy link
Member Author

@NickLaMuro NickLaMuro left a comment

Choose a reason for hiding this comment

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

Just a few notes on what I did for context.

@@ -18,6 +18,10 @@ def execute(action)
launch_ansible_job_queue(action)
end

def check_connection(action)
Copy link
Member Author

Choose a reason for hiding this comment

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

The action argument here is just in line with how playbook also works. If this interface, and the one in ServiceTemplateAnsiblePlaybook, are incorrect, we can change, but it seems like this is how these methods function.

(by that, I mean they pass around a :provision keyword to access specific attributes in config_info)

# repo in a temp path to check the remote to see if it can accept
# connections.
def check_connection
Dir.mktmpdir do |tmp_repo_dir|
Copy link
Member Author

Choose a reason for hiding this comment

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

Doing this as a block to make sure the tmp dir is removed once we are done with the .check_connection call.

The result of the block is what is returned, so the directory being deleted is just a side effect of that.

app/models/git_repository.rb Show resolved Hide resolved
with_remote_options do |remote_options|
@repo.remotes
.create_anonymous(url)
.check_connection(:fetch, remote_options)
Copy link
Member Author

Choose a reason for hiding this comment

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

remote_options here has our credentials and proxy info, so if that is configured, it will be used as it is with other methods in this class.

Copy link
Member

Choose a reason for hiding this comment

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

Is check_connection here a rugged method?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member

@kbrock kbrock left a comment

Choose a reason for hiding this comment

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

code checks out for me.

Like the approach and am happy we are not over optimizing this before we even get the thing up and running. The point that seals the deal for me is knowing that if there were a performance problem, Nick would not be the only one able to diagnose and fix this problem.

This looks great.

Tina - let me know if this checks out on your side and I can merge.
Or if you are not able to test, ping me and I can take a look

@d-m-u
Copy link
Contributor

d-m-u commented Oct 7, 2020

Not sure why the enhancement label, pretty sure this is a bug: see the linked bz in the description (https://bugzilla.redhat.com/show_bug.cgi?id=1835226).

@NickLaMuro
Copy link
Member Author

@d-m-u while this PR itself is addressing a bug, but the addition is a enhancement that didn't exist previously.

@NickLaMuro NickLaMuro changed the title Add ServiceAnsiblePlaybook.check_connection [WIP] Add ServiceAnsiblePlaybook.check_connection Oct 7, 2020
@NickLaMuro
Copy link
Member Author

Marking this as [WIP] for now while we determine what is causing a segfault with this code.

@miq-bot miq-bot added the wip label Oct 7, 2020
@NickLaMuro
Copy link
Member Author

So I wanted to give an update on this...

I have been unable to replicate the segfault on another VM, and importing the automate domain properly was a research project in it of itself, so I am a bit stuck.

I think Drew has replicated this issue multiple times now, but I honestly don't know where to start on fixing the segfault and have been spinning my wheels a bit on where to start. I might consider a shell out to git ls-remote if it comes to that, though that would be a much more involved process to do just that, and probably deserves it's own separate class for handling it.

Anyway, thought I would give a bit of an update since this has been staled as a result of me not being able to figure this bug out... 😞

@NickLaMuro
Copy link
Member Author

Leaving this as a note for myself. I think this might be a inter-opt issue with DRb, but not positive. If we are trying to work with a c-extension over DRb, I could see that potentially causing weird issues with this code and causing said segfault to happen.

That said, I currently haven't been able to recreate and setting something up to do just that has been a bit of a nightmare, so will probably work with Drew and Tina next week to work on this.

@tinaafitz
Copy link
Member

tinaafitz commented Oct 12, 2020

Hi @NickLaMuro, Thanks so much for your work on this and for the update. I know we discussed it briefly on our call on Friday, but I'm happy to get on a call to discuss it whenever it works best for you.

I was hoping this simplified way of running the Automate check_connection method through the rails console would reproduce the segfault, but it didn't. :-(

#setup the Automate workspace $evm=MiqAeMethodService::MiqAeService.new(MiqAeEngine::MiqAeWorkspaceRuntime.new)

#get the service model wrapped Service object
sm_s = $evm.vmdb('service', 80)

sm_s.check_connection("provision")

@NickLaMuro
Copy link
Member Author

After some major troubles with segfaults that @tinaafitz and Co have been having, I think we are going to abandon this PR in favor of an alternative solution. Going to close, and we can re-open if we change our minds.

@@ -258,6 +258,14 @@ def checkout
end
end

def check_connection(url)
Copy link
Contributor

Choose a reason for hiding this comment

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

I know this is closed, but just as a note for me so I don't lose context, we were in the process of replacing this method with Net::Ping::HTTP.new(url).ping? when we hit the subsequent error about the job not existing.

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