-
Notifications
You must be signed in to change notification settings - Fork 2.3k
[mod] container: replace uWSGI with Granian #4820
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
Conversation
|
FYI: I changed Docker users often forget: "there is life outside the container" ;-) .. we have shell scripts and documentation .. sorry if I insist: in commit messages, I often miss the reference which is only given in the PR intro message. If a commit, for example, has a reference to a proposal or an issue, then this reference should also be included in the commit message. Please read the description of Basically, the commit message should contain all the information that the PR intro comment also has. Since the commit message always exists before the PR, I always write everything in the commit message and then simply copy this message into the PR (GH already copies the commit message when creating the PR). |
I'm not saying no, I'm now updating the docs and adding the new Granian section, but the scripts? Wouldn't it be more prudent to first test migrating the container users and then providing in another PR the migration for the rest of those who decide to do the normal installation route? I can convert this PR to migrate the whole stack to Granian including all installation routes, but I'm afraid it's going to be quite a big change. |
No, this was not my intention .. these are different tasks and the scope of this PR is docker .. nothing more .. I just wanted to say "we can't close the feature request #4479 before all tasks are done" .. sorry if I was unclear. |
|
Regarding #4891 (comment) ... This is the first revision of the documentation, can you check if it's OK, or should I modify something? |
30206d5 to
39983ed
Compare
|
Rebases on master to fix merge conflicts, no changes were made. |
Bnyro
left a comment
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.
Looks awesome, can't wait to use it on my instance :)
I've left some small comments about the configuration, the general changes structure looks good to me though :)
Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment)
Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment)
|
Rebases on master to fix merge conflicts, no changes were made. |
The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything. It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration. In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV `FORCE_OWNERSHIP=false` will prevent ownership from being modified. No manual migration is necessary **unless** the user has changed the default uWSGI configuration or has a very specific setup. Closes searxng#4894 Closes searxng#4818 Closes searxng#4802 Supersedes searxng#4596 Related searxng#4479
All container documentation has been recreated. A new documentation page has been created for Granian.
Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment)
return42
left a comment
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.
looks awesome 👍 .. I placed a WIP commit on top, we can squash before merge this PR .. In the WIP commit there are only minor changes to the documentation .. no significant changes.
|
@inetol your last force push removes some (small) modifications from my WIP commit, see docs/admin/installation-granian.rst .. these are only nits, but why did you removed them? |
It looks redundant, since we are already on Granian page. When making a reference from somewhere else, it is seen with the anchor name and not the header title, isn't it? |
Bnyro
left a comment
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've been using this on my instance for the past week and didn't encounter any issues, so lgtm in that regard 👍
lorem ipsum `Granian options`_
.. _Granian options: https://github.com/emmett-framework/granian/blob/master/README.md#optionswill be rendered to: lorem ipsum Granian options lorem ipsum :ref:`Granian configuration`
.. _Granian configuration:
Config
======
...
will be rendered to header title .. lorem ipsum Config To verify your modifications, use If you don't want to see the header title you can use a notation like this .. lorem ipsum :ref:`Granian config <Granian configuration>`lorem ipsum Granian config A short introduce can be found in our primer: Anchors & Links |
|
@inetol after a cleanup of the git history (squash the last 3 commits into the 2 first commits) this PR is ready to merge I think .. will you squash and merge .. or should I do it? |
|
GH: #4972 |
Minor documentation changes. Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Suggested searxng#4820 (comment) Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
The configuration in Granian is handled with ENVs, much more convenient and practical for updating. The settings have been tested for over two months in a production instance, being usable on small to somewhat large instances without having to modify anything.
It also removes the patch functions and ENVs abstraction from the entrypoint, this makes it possible to run the container with immutable configuration.
In some setups, It may be desired to have the volumes/files under a specific uid/gid (other than searxng:searxng), if the entrypoint has root permissions it will chown automatically on every start, which may not be desired. Explicitly setting the new ENV
FORCE_OWNERSHIP=falsewill prevent ownership from being modified.Those changes are reflected in the documentation, which also received a rework.
No manual migration is necessary unless the user has changed the default uWSGI configuration or has a very specific setup.
Closes #4894
Closes #4818
Closes #4802
Supersedes #4596
Related #4479
Latest CI: https://github.com/inetol/searxng/actions/runs/15582123713