Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Daniel Berger
    @djberg96
    something like "libssh not found" or maybe zlib
    thesystemninjaneer
    @thesystemninjaneer
    whoops left out the part that i only poked around in the rugged mkmf.log.
    Daniel Berger
    @djberg96
    yes, it would be in there
    thesystemninjaneer
    @thesystemninjaneer
    @djberg96 ok let me check
    Daniel Berger
    @djberg96
    any warnings/errors really
    the reason i ask is that it could fail with that error message if "ssh://", "ssh+git://" or "git+ssh://" is the protocol, but GIT_SSH is not defined, based on what i'm seeing in the source, plus various googling
    thesystemninjaneer
    @thesystemninjaneer
    i found 6 matches for a grep on string 'not found'.
    • rugged: pthread_create, pthread_create in pthreads, regcomp_l, qsort_s, http-parser version 2
    • ffi: libffi
    Daniel Berger
    @djberg96
    any chance you could gist the mkmf.log for rugged?
    thesystemninjaneer
    @thesystemninjaneer
    no, sorry.
    Daniel Berger
    @djberg96
    hm, http-parser, that's a dep for libgit i think
    thesystemninjaneer
    @thesystemninjaneer
    actually, just checked the jansa-2 container i ran from outside my corp environment and it has the same mkmf.log matches. guessing anyone running that container will see the same thing since i havent modified it at all.
    let me get you the sha of that container
    here you go sha256:b52b4f25dfc6ddf23d94607feb6ee9f5126ba4ab8323916731060acb78ebf2b7. curious if anyone else sees those same not found messages
    brb
    thesystemninjaneer
    @thesystemninjaneer
    back
    Nick LaMuro
    @NickLaMuro

    @djberg96 So I think what you are trying to check for something like this being the case, right:

    https://github.com/ManageIQ/manageiq/blob/1e7fe382160130bdf318713304f3cf46fe9f479b/lib/git_worktree.rb#L40-L55

    Daniel Berger
    @djberg96
    yeah, i guess that error would pop up instead
    actually we can check
    @thesystemninjaneer can you tell us what the output of Rugged.features.include?(:ssh) is on the console?
    thesystemninjaneer
    @thesystemninjaneer
    sure
    thesystemninjaneer
    @thesystemninjaneer
    @djberg96 => true
    Daniel Berger
    @djberg96
    ok, would seem to kill that theory
    thesystemninjaneer
    @thesystemninjaneer
    @djberg96 @NickLaMuro finally had a breakthrough
    This message was deleted
    thesystemninjaneer
    @thesystemninjaneer
    1. made a fresh new repo in our internal gitlab server git@gitlab.EXAMPLE.COM:TEAMNAME/miqtest.git
    2. add a single helloworld playbook into its dev branch
    3. add the same deploy key to it as all the other working repos used
    4. added a new miqtest ansible repository for git@gitlab.EXAMPLE.COM:TEAMNAME/miqtest.git
    5. added a new helloworld-miqtest automation service using the miqtest ansible repo
    6. ordered the service and it ran successfully
    then i scratched my head for a minute wondering what was different about the original repo git@gitlab.EXAMPLE.COM:TEAMNAME/miq.git
    thesystemninjaneer
    @thesystemninjaneer
    then remembered my miq.git repo had a .gitmodules file including another repo in our TEAMNAME team referencing it as url = ../ANOTHERREPO via relative path per this gitlab config doc. i wondered if Rugged was possible being so thorough it was picking up the git submodule dependency and also trying to pul the url ../ANOTHERREPO relative path which may explain the unsupported url error we kept seeing.
    as a quick test, i checked in the same .gitmodule file from git@gitlab.EXAMPLE.COM:TEAMNAME/miq.git into the working git@gitlab.EXAMPLE.COM:TEAMNAME/miqtest.git repo and it also started failing with the same errors.
    given those test results would it be safe to say, as miq & rugged operate today (jansa-2), embedded ansible playbooks containing git sub modules are not supported?
    Nick LaMuro
    @NickLaMuro
    they are, but not very well
    (I was going to ask about submodules too... and then I didn't... sorry about that)
    effectively, the submodules are currently cloned for each .checkout, since rugged doesn't support the cli equivalents of git submodule init and git submodule update
    we can parse through them and determine their root URL, but they are very finicky
    thesystemninjaneer
    @thesystemninjaneer
    Is it a relative path vs ssh/https url thing then?
    Nick LaMuro
    @NickLaMuro
    I would say even more than that. Because we have to assume the one auth that is there, the submodules basically have to be just as accessible as the root repo. I am not even sure if you can say: "have a ssh base repo, with a https submodule"
    let me look what I did... because I had to pseudo support this a few months ago
    thesystemninjaneer
    @thesystemninjaneer
    ok. I did create a deploy key specifically for the miq.git & miqtest repo and did not have that key enabled on the submodule. A message like “submodule ‘foo’ detected within repo and will be cloned using the same credential. Would you still like to add?” would be a cool prompt when the user attempts to add a new ansible repo that has a .gitmodule file. Not sure if this scenario is too unique though to justify adding a repo scan to the provider code though.
    Nick LaMuro
    @NickLaMuro
    that doesn't sound like a bad idea. Do you want to open up an issue in ManageIQ/manageiq to flesh out that idea a bit more so we can get a discussion going on it?
    thesystemninjaneer
    @thesystemninjaneer
    It definitely threw me that it allowed adding the playbook repo and was able to discover playbooks without throwing an error at that point. Can get you an issue in the morning with some of these details. Have a good night.
    Nick LaMuro
    @NickLaMuro

    sounds good.

    for some extended info: The bare repo clone doesn't bother with submodules, and they are only handled on checkout:

    https://github.com/ManageIQ/manageiq/blob/3288db91c705bcef8aa916dcaac9a3310cc3515b/lib/git_worktree.rb#L240-L259

    But I don't think it would be unreasonable to at least provide some kind of check after a clone to provide some kind of info to the user that submodules aren't 100% supported.

    Also, this probably won't be able to be a "Would you still like to add?" sort of thing since the sync actually does happen aync after a save, and the repo might not exist on the MiqServer that is serving the request. So I think it is something that will have to be a combination of a Notification and an extra database boolean column that can be queried against, and then brought up as a warning when viewing the repo.

    Daniel Berger
    @djberg96
    wow, interesting
    there's a Rugged::Submodule, if that's of any use
    thesystemninjaneer
    @thesystemninjaneer
    issue created ManageIQ/manageiq#20779
    Nick LaMuro
    @NickLaMuro
    @thesystemninjaneer thanks!

    @djberg96 there is a Rugged::Submodule, which we do use, but it only really looks at the what the sub modules are configured as, and doesn't do a really good job of providing a .fetch mechanism, specifically with bare repos.

    So I basically had to make one up myself using .clone for each one. And it has to do a full clone to since Rugged also doesn't support shallow clones...

    Daniel Berger
    @djberg96
    @NickLaMuro is it a rugged issue, or a libgit2 issue?
    not trying to split hairs, just wondering if it's something we could easily add, or if it means mucking around in C code
    Nick LaMuro
    @NickLaMuro
    I think from what I remember, the support doesn't exist yet in libgit2, so it would be a lot of C code additions
    and I don't know that it is a priority for the GitHub team backing it
    Daniel Berger
    @djberg96
    ok