-
-
Notifications
You must be signed in to change notification settings - Fork 441
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
Issue #140: Added a memory-limit setting for the CLI #347
base: master
Are you sure you want to change the base?
Conversation
block: | ||
- name: Ensure PHP CLI config directory exists. | ||
file: | ||
dest: "/etc/php/{{ php_default_version_debian }}/cli/conf.d/" |
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.
Do we have this set up for RedHat-derivatives too?
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.
@geerlingguy No, sorry. We've standardized on Ubuntu LTS over here; I don't typically work with non-Debian-based OSes (and wouldn't recommend them, but that's another story). What I'd recommend doing, which is what we do for Aegir, is get support for each alternative component as it comes in. So whenever this is good to go, merge it, but leave the issue open for someone else to come along and work on the Red Hat support (and then close it once that gets in). Would that work for you?
I'll take a look at the Lint problems and see if I can get those fixed.
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.
Tests were passing for Red Hat though. So maybe it's all good?
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'd still rather not merge it if it only works on Debian.
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.
@geerlingguy But if tests are passing, doesn't this prove that it also works on Red Hat, or whatever?
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.
well
- you're adding a feature that'll be only compatible with 1 out of X OS options
- tests are not that extensive, you could make a test that shows it doesn't work on RHEL distros and fix it accordingly
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.
The role still works, but if I add a feature that has a default variable that only applies to one distro (or a few) of any that are supported, then I start having to remember (for myself) which features of the role work on only one distro but not the other, and I have to start adding complexity to the documentation for features which shouldn't need to be distro-specific.
I prefer for my own roles to have defaults that work across any distro the role supports, but I'm always happy for people to fork my roles and modify them according to their own needs. I typically only add features that work on all distros unless it's something extremely specific to one OS (e.g. apt PPA url settings).
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.
Fair points. To benefit everyone, however, can we tag this as Planned and then let others push to the PR to complete it eventually, when someone else gets to it? GitLab allows this, but I don't work on GitHub enough to know if that's possible here.
Unless someone is able to provide funding (please contact us if interested), I have no plans to add Red Hat support here, but it would be a shame to simply throw away the work I did.
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.
Sure, I have no problem with that—it's useful functionality, and if someone can come along and make it work on RHEL/RockyLinux as well, I'd be happy to merge.
I fixed all of the Lint problems except for something in the "Unchanged files with check annotations" section, which I didn't want to touch because it has nothing to do with this issue. |
+1 if all issues have been addressed and the CI is passing we could merge? |
This pull request has been marked 'stale' due to lack of recent activity. If there is no further activity, the PR will be closed in another 30 days. Thank you for your contribution! Please read this blog post to see the reasons why I mark pull requests as stale. |
Sounds good to me. |
This issue is no longer marked for closure. |
This pull request has been marked 'stale' due to lack of recent activity. If there is no further activity, the PR will be closed in another 30 days. Thank you for your contribution! Please read this blog post to see the reasons why I mark pull requests as stale. |
This is still ready for merging. |
This issue is no longer marked for closure. |
Looking over the existing Ansible tasks, the role writes the same PHP.ini for each of the Default includes fpm, apache2, cli. Maybe a different approach could be to allow overriding template vars just for the specified conf file? Not exactly sure how this could be done, but I'm going to look into it. Or, overrides could be added to the conf.d dir as well... Will keep you posted.
|
As per #140, we need a way to set a different memory limit on the CLI.
This should work for the Debian family, at least.
Cherry-picked from consensus-enterprises@f59f296.