Add rockstor-build systemd service #2793
Assignees
Milestone
Comments
Dev notesOur 'flag' condition: we only run if the .venv does not exist. Such as after an rpm upgrade; where we are then required to re-establish the .venv to the new specifications defined by the freshly installed package. |
rockstor-build.serviceWith no .venv dir, and in this test case also no Poetry, we have the following status output from the proposed rockstor-build service: |
No .venv so rockstor-build is run:
subsequent bootWe have our .venv so the build service is not executed:
|
Poetry-install-txtContents generated from build.sh's execution from within systemd via the proposed (in pending PR) rockstor-build.service during a boot where our pipx installed Poetry was not installed, and there was no existing flag/venv dir of .venv: |
phillxnet
added a commit
to phillxnet/rockstor-core
that referenced
this issue
Feb 1, 2024
Move build.sh execution from within rpm %posttrans script to it's own dedicated rockstor-build.service. Enabling greater fidelity and control over the environment and timing; and eases development and user feedback on build.sh failures in the future. Partnered with rockstor.spec changes in rockstor-rpmbuild repo. ## Includes - New rockstor-build.service file. - After= & Requires= entries in rockstor-pre on rockstor-build, to extend our service cascade. - Trivial build.sh and pkg_mgmt.py comment updates. - Add the new rockstor-build.service to initrock.py to assist in asserting the service akin to all other rockstor services. Mostly redundant given our rpm service management, but nice-to-have.
|
good stuff! |
phillxnet
added a commit
that referenced
this issue
Feb 2, 2024
…md-service Add rockstor-build systemd service #2793
|
Closing as: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It is proposed that we move the executing of our build.sh shell script, from the rpm %posttrans scriptlet, to a one-shot systemd service that runs if of our .venv directory is not found. Our Python virtual environment is a pre-requisite of our other services and as such we can more easily user surface & develop this scripts failure/function if it is more properly located within our host OS's main orchestration.
Our current use of rpm's %posttrans scriptlet has surfaced a number of sensitivities/constraint, indicating that we are likely stretching the intended use of this somewhat constrained post rpm transaction scriptlet: i.e. contents are executed after the rpm package transaction has completed (we need our new build.sh to be in place after all) but we then face the constraints of a failed %posttrans execution and it's consequent failure to our other systemd services (no .venv). Moving/delaying build.sh's execution to the systemd services phase, which are auto-started post rpm install, means we can more properly place our required early OS arrangement under OS orchestration, rather than squeezing them into the constrained/limited last step of the packaging system.
It would also be significantly easier to develop further on build.sh it it were run from a more configurable environment such as systemd is designed to provide. As-is we have had a number of failures that pertain only to rpm's scriptlet env that otherwise are not seen in a regular terminal. And build.sh testing is then trivially accomplished by exercising it's proposed dedicated systemd script, rather than having to build an rpm and test that rpms's install/update function just to ensure we maintain function in that env.
We are also likely over-stepping the intended boundaries of %posttrans when we install additional programs; e.g our uninstall/install/upgrade maintenance of our build system Poetry: such as we do in build.sh. And additionally we are, more recently, using OS provided pipx to do this. Further complicating our requirements of a packaging system.
There are also odd corner cases to our current approach such as has recently been discovered in our latest installer build developments. See:
"Tumbleweed: build.sh fails as no /etc/locale.conf": rockstor/rockstor-installer#156
However this would dictate that our installer will have to have internet access in order that the first invocation of rockstor-build.service could download from PyPi our required .venv dependencies. But that is assumed for a modern OS instance anyway for all other OS updates. It would also remove the special case of our installer having a pre-build .venv when no other rpm has this: our rpm install/update auto-wipes the install location prior .venv directory: hence using this as an flag for build.sh's systemd service execution.
The text was updated successfully, but these errors were encountered: