Skip to content

Conversation

@scottjg
Copy link
Contributor

@scottjg scottjg commented Jan 12, 2024

my attempt at adding the opensearch package. there is an existing homebrew package that i used as a reference. this is my first time contributing to the pantry so please let me know if any changes are needed.

i would also like to contribute building the k-NN plugin and native binaries for opensearch. this is normally shipped with opensearch binaries by the upstream project but annoyingly they don't include the native libraries for macos despite them working fine on the platform. i was hoping someone could maybe point me at an example of including a second distribution tarball.

Copy link
Contributor

@jhheider jhheider left a comment

Choose a reason for hiding this comment

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

looks good; just some style notes.

Comment on lines 17 to 28
- gradle -Dbuild.snapshot=false ":distribution:archives:no-jdk-{{hw.platform}}-tar:assemble"
- mkdir -p "{{prefix}}"
- tar --strip-components=1 -xf distribution/archives/no-jdk-{{hw.platform}}-tar/build/distributions/opensearch-*.tar.gz -C "{{prefix}}"
Copy link
Contributor

Choose a reason for hiding this comment

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

what a weird way to have to do it; sadly, python poetry is similar.

@jhheider
Copy link
Contributor

i would also like to contribute building the k-NN plugin and native binaries for opensearch. this is normally shipped with opensearch binaries by the upstream project but annoyingly they don't include the native libraries for macos despite them working fine on the platform. i was hoping someone could maybe point me at an example of including a second distribution tarball.

you should be able to add it to the install script, assuming you can build all the required parameters. would you like me to wait until you add that to merge?

@scottjg
Copy link
Contributor Author

scottjg commented Jan 12, 2024

sure - let me dig into it.

./gradlew publishPluginZipPublicationToZipStagingRepository -Dopensearch.version={{version}} -Dbuild.snapshot=false -Dbuild.version_qualifier=
./gradlew publishPluginZipPublicationToMavenLocal -Dbuild.snapshot=false -Dbuild.version_qualifier= -Dopensearch.version={{version}}
mkdir -p ./build/distributions/lib
cp -v ./jni/release/libopensearchknn* ./build/distributions/lib
Copy link
Contributor Author

@scottjg scottjg Jan 12, 2024

Choose a reason for hiding this comment

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

this build generates native libraries with the .jnilib extension. when i was packaging this for my team (pre-pkgx) i had to codesign and notarize the libraries. i know you guys have some infra around this stuff already but i just wanted to make sure since it wasn't a dylib that it would be ok?

it seems to work locally fwiw.

Copy link
Contributor

Choose a reason for hiding this comment

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

generally, yes, our codesigning logic has worked for over a year. the only package i can see that's needed anything different is: https://github.com/pkgxdev/pantry/blob/main/projects/github.com/sindresorhus/macos-term-size/package.yml

@scottjg
Copy link
Contributor Author

scottjg commented Jan 13, 2024

oops, sorry.. didn't see that force push. might've clobbered each other there.

@jhheider
Copy link
Contributor

no worries; i just did update-with-rebase

includes knn plugin
@scottjg
Copy link
Contributor Author

scottjg commented Jan 13, 2024

great progress here, but still a few issues.

  • mac x86-64 build: seems to be having some kind of networking issue (maybe?) fetching a manifest
  • mac m1 build: rpaths are not properly cleaned up in the jnilibs and they fail to load
  • linux builds: likely similar rpath issues but tests don't run on them

@jhheider
Copy link
Contributor

from boost.org:

    # boost.org has libs that end up with name @rpath/libboost_atomic.dylib (offset 24)
    # so we need to add @loader_path to the rpath
    - run: |
        for LIB in *.dylib; do
          install_name_tool -add_rpath @loader_path $LIB
        done
      working-directory: ${{prefix}}/lib
      if: darwin

i'll re-run darwin-x86_64 once the rest finish (though it should have the same issue).

linux doesn't use rpath, so that's not likely to affect them. it uses LD_LIBRARY_PATH, which we set. looks like linux-aarch64 passed (unless you mean it has no tests).

@jhheider
Copy link
Contributor

that .meta url is fine, so something is up with JsonSlurper on darwin-x86-64. i wonder if it's relying on a system tool that isn't present. probably have to try one of these to see why:

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.

@scottjg
Copy link
Contributor Author

scottjg commented Jan 13, 2024

linux doesn't use rpath, so that's not likely to affect them. it uses LD_LIBRARY_PATH, which we set. looks like linux-aarch64 passed (unless you mean it has no tests).

the real tests i wrote in the yml only run on darwin. opensearch can't run as root (mysql package has a similar comment in it), so i just output the version instead which can at least sanity check the package. the problem is that the knn plugin is lazily loaded so that's not really tested at all on linux.

maybe there's some simple-ish solution munging env with sudo to make that work.

that .meta url is fine, so something is up with JsonSlurper on darwin-x86-64. i wonder if it's relying on a system tool that isn't present. probably have to try one of these to see why:

makes sense. unfortunately past my bedtime so will have to try in the morning.

getting close though! m1 build is totally working end to end.

@scottjg
Copy link
Contributor Author

scottjg commented Jan 13, 2024

mysql package has a similar comment in it

err, i meant postgres

test:
script: |
# While we'd love a good test like this, `initdb` doesn't run as root, and managing
# all the environment passthrough with `sudo` is a nightmare.
if test "{{ hw.platform }}" = "linux"; then

@scottjg
Copy link
Contributor Author

scottjg commented Jan 13, 2024

not sure what happened with that JsonSlurper issue but it's gone this morning. i also sanity checked the linux build locally and it seemed to work. i think this is ready for a final review.

@jhheider
Copy link
Contributor

looks good. i tried to clean up the various cds with working-directories: to make the flow more clear. however, if i didn't follow it, i might have messed it up. we'll know after it builds.

@scottjg
Copy link
Contributor Author

scottjg commented Jan 14, 2024

nice!

@jhheider jhheider merged commit 488f027 into pkgxdev:main Jan 14, 2024
@jhheider
Copy link
Contributor

And there we go. That was a big one. Thanks @scottjg !

@jhheider
Copy link
Contributor

hm, failing to find libc on macos12: https://github.com/pkgxdev/pantry/actions/runs/7516912520/job/20462627197

possibly we need to add an rpath somewhere?

zip -r opensearch-knn-{{version}}.0.zip lib/
{{prefix}}/bin/opensearch-plugin install --batch file:`pwd`/opensearch-knn-{{version}}.0.zip
working-directory: k-NN
- run: echo 'export OPENSEARCH_JAVA_OPTS="-Djava.library.path=$OPENSEARCH_HOME/plugins/opensearch-knn/lib $OPENSEARCH_JAVA_OPTS"' >> opensearch-env
Copy link
Contributor Author

Choose a reason for hiding this comment

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

if it's happening when opensearch boots, then it shouldn't be loading the knn plugin yet. it might be related to this.

i tried to modify the java library path here so that the native plugin dependencies would be loaded properly. maybe it needs some more paths? hmm...

Copy link
Contributor

Choose a reason for hiding this comment

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

does it maybe need a runtime.env.OPENSEARCH_JAVA_OPTS: key?

@scottjg
Copy link
Contributor Author

scottjg commented Jan 14, 2024

so, i guess it's in opensearch itself where it's trying to call setrlimit which presumably is why it's trying to load libc

java.lang.UnsatisfiedLinkError: 'int org.opensearch.bootstrap.JNACLibrary.setrlimit(int, org.opensearch.bootstrap.JNACLibrary$Rlimit)'
	at org.opensearch.bootstrap.JNACLibrary.setrlimit(Native Method) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.SystemCallFilter.bsdImpl(SystemCallFilter.java:609) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.SystemCallFilter.init(SystemCallFilter.java:669) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.JNANatives.tryInstallSystemCallFilter(JNANatives.java:281) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.Natives.tryInstallSystemCallFilter(Natives.java:128) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:129) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.Bootstrap.setup(Bootstrap.java:191) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.Bootstrap.init(Bootstrap.java:404) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.OpenSearch.init(OpenSearch.java:180) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.OpenSearch.execute(OpenSearch.java:171) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:104) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.cli.Command.mainWithoutErrorHandling(Command.java:138) ~[opensearch-cli-2.11.1.jar:2.11.1]
	at org.opensearch.cli.Command.main(Command.java:101) ~[opensearch-cli-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:137) ~[opensearch-2.11.1.jar:2.11.1]
	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:103) ~[opensearch-2.11.1.jar:2.11.1]

@scottjg
Copy link
Contributor Author

scottjg commented Jan 14, 2024

#4841

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants