Hi,
I've packaged 0.5.0-beta in rpm for our Enterprise Linux 9 environment, and just wanted to provide a bit of early feedback, mostly focused on the new local-daemon.
Feedback for building:
The "daemon" directory could actually be a separate project/codebase, since AFAIK nothing makes it PHP specific and other programming languages could have the same production deployment limitations as php-fpm and benefit from using it.
The daemon/asld_kvs.proto is weirdly required/included from the PHP extension build (possibly the reason why everything is a single codebase?).
There are confusing inconsistencies in the naming "daemon" (dir), "aerospike-local-daemon" (in some places) and "asld" (in others). See the daemon/Dockerfile for instance.
The daemon/Makefile is quite messy. Targets that require building don't even use the "build" target. The "build" target doesn't even work on its own since it requires "proto" first. And the default is "run" which tries to do waaaay too much: installing with sudo, and enabling and starting the service. I would have expected the default to result in getting the binary built (so probably proto & build), and the install to be in its own "install" target to be run as "sudo make install" for anyone wanting to leverage it.
The systemd file install seems broken (no file where it's expected) and the pkg/build/usr/lib/systemd/system/ one has a leftover name of aerospike-prometheus-exporter.service. For us an example file with instructions to copy/paste would be better. Or this done as part of the install target, and supporting a DESTDIR prefix.
The golang version requirement is 1.21.3 while el9 currently ships with 1.20, so we had to rebuild 1.22 for el9. This raises the entry bar for building from sources, but isn't really an issue if the project is expected to be provided in binary releases in the future.
The make proto requires protoc-gen-go-grpc and protoc-gen-go programs to be available, which is really not straightforward on el9 (these are part of Google golang projects). For now, we are running that on Fedora when preparing the tarball to use in our source rpm as a workaround. If the project implements in the future some sort of make dist that runs this in order to bundle the output files in a release tarball, that would fix this issue.
Feedback for running:
The local-daemon doesn't allow for specifying the listening socket file mode. This would be useful to control access to a certain degree (though we will probably place the socket inside a directory with ACLs for finer grained access control).
The local-daemon's socket file doesn't seem to get unlinked when shutting down, and it doesn't seem to try and unlink or reuse the existing socket file at startup. If it could do both, cleanup at exit and cleanup at start, it would be a lot more reliable for us.
Hi, I've packaged 0.5.0-beta in rpm for our Enterprise Linux 9 environment, and just wanted to provide a bit of early feedback, mostly focused on the new local-daemon.
Feedback for building:
daemon/asld_kvs.proto
is weirdly required/included from the PHP extension build (possibly the reason why everything is a single codebase?).daemon/Dockerfile
for instance.daemon/Makefile
is quite messy. Targets that require building don't even use the "build" target. The "build" target doesn't even work on its own since it requires "proto" first. And the default is "run" which tries to do waaaay too much: installing with sudo, and enabling and starting the service. I would have expected the default to result in getting the binary built (so probably proto & build), and the install to be in its own "install" target to be run as "sudo make install" for anyone wanting to leverage it.pkg/build/usr/lib/systemd/system/
one has a leftover name ofaerospike-prometheus-exporter.service
. For us an example file with instructions to copy/paste would be better. Or this done as part of the install target, and supporting aDESTDIR
prefix.make proto
requiresprotoc-gen-go-grpc
andprotoc-gen-go
programs to be available, which is really not straightforward on el9 (these are part of Google golang projects). For now, we are running that on Fedora when preparing the tarball to use in our source rpm as a workaround. If the project implements in the future some sort ofmake dist
that runs this in order to bundle the output files in a release tarball, that would fix this issue.Feedback for running:
Our rpm build spec file and source prep script are available here: https://github.com/exogroup/rpms/tree/master/php-aerospike
Thanks for taking this one big step further towards being usable in production php-fpm environments! Matthias