-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: implement basic "install" command #1
Conversation
0ad9a11
to
b53226d
Compare
Welcome to Codecov 🎉Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests. Thanks for integrating Codecov - We've got you covered ☂️ |
e7be920
to
91fe3ad
Compare
91fe3ad
to
f35b63a
Compare
f35b63a
to
bf85861
Compare
bf85861
to
e1856b9
Compare
86740eb
to
32dc2cc
Compare
At this point, the "install" command simply copies the template files to the right places in the user's XDG directory tree and invokes the `systemctl` commands to reload the daemon to recognize the new/updated units. This basic functionality does not include any support for the "override" files. That will come later. This commit also includes placeholder code for commands "reset_django_secret" and "reset_server_password" that currently do nothing. They will come later.
6eea67c
to
0bd58d5
Compare
0bd58d5
to
4ed7067
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love what I see here!
I only left one comment but feel free to ignore it.
Thanks to @bruno-fs for suggesting this change! Co-authored-by: Bruno FS Ciconelle <[email protected]>
This PR demonstrates a prototype for how we might build out commands for installing, maintaining, and troubleshooting a quipucords server through this
quipucordsctl
package/program. The overall design is intended to enable more commands to be added easily over time or to add specific commands only in certain environments. Commands are dynamically loaded from thecommands
package; so, a user could install additional custom commands there, or maybe we would add a setting to load additional commands from another path. Maybediscovery-ci
could benefit from this, but I doubt many of our "real" customer users would be interested in writing custom commands. Maybe SEAP or SAs would having some unique ideas for commands? If they did, we'd probably ask to incorporate them into the project properly.This program is not intended to replace
qpc
which is a client for thequipucords
service. This program does not interact with thequipucords
APIs; this program manages the installation itself like the oldquipucords-installer
does.This PR uses only standard library functionality from Python. It uses Poetry to install development dependencies (
ruff
,pytest
), but the actual runtime has no dependencies outside Python 3.12 itself. This is a deliberate design choice because this tool will eventually be downstreamed and packaged and shipped to RHEL repos, and we do not have a great variety of useful modern third-party Python libraries available there. This project may eventually vendor some small third-party dependencies, but that is a discussion for a future day.This PR currently includes only a partially-working
install
command. Effectively, it just creates directories, copies files, and invokes twosystemctl
commands. The code does include several placeholders andTODO
comments where I intend to continue expanding this work. Next steps, assuming we agree on this approach, would be to implement setting the server password and Django secret, applying the "overrides" templates, and adding anuninstall
command. We would build a propersetup.py
andspec
file to make everything RPM-installable. At that point, we would have feature parity with the oldquipucords-installer
, and we could start implementing new commands for checking container status/health, getting logs, dumping the database, etc.Also, unlike
quipucords-installer
, high unit test coverage. Finally. 🎉Currently, you can invoke the program like this:
Using multiple verbose flags drives the log level down (i.e. more output).
Once we build
setup.py
and thespec
file, the program would be invoked simply asquipucordsctl
.