-
Notifications
You must be signed in to change notification settings - Fork 30
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
Fixes #30423 - Change the application layout #115
Conversation
The migration can be done by moving |
owner => $pulpcore::user, | ||
group => $pulpcore::group, | ||
mode => '0775', |
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.
So I've learned this may give problems when sharing this directory with Pulp 2. We don't add the Apache user to the pulp group. Looking into this now.
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.
So it turns out Pulp 2's spec file does this: https://github.com/pulp/pulp-packaging/blob/7c05ec9c678c01aa9c6a40f8e3a8be4b1aa9c50d/packages/pulp/pulp.spec#L500
It's lovely that /var/lib/pulp
is also owned by pulp-server but with different ownership:
https://github.com/pulp/pulp-packaging/blob/7c05ec9c678c01aa9c6a40f8e3a8be4b1aa9c50d/packages/pulp/pulp.spec#L484-L485
This means rpm -qV pulpserver
will result in warnings.
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.
If I understand correctly, this means your implementation should work whether it's working alongside pulp2 or a future new install that is pulp3 only? Because the group membership is only required by Pulp2 and is handled by Pulp2 packaging.
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.
Yes, I wasn't aware Pulp 2 packaging did that and thought it was something the installer needed to do.
manifests/init.pp
Outdated
# include pulpcore | ||
# | ||
# @example Disable static content |
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.
@ekohl can you help me understand this use case? why would an user want to disable management of static content ?
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.
Static content is only the CSS/JS and you don't need that for the API. Right now in our deployment we don't even serve it and we've shipped that to users.
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.
@ekohl My understanding is that it does allow for a nicer presentation of the api docs... Is that something that we don't expect a Katello user to interact with directly?
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.
My thinking is that from a troubleshooting standpoint that would be nice to have in the Katello scenario, particularly given that there isn't a pulp-admin
equivalent for Pulp3.
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 think so and it is a goal, but right now we don't serve them at all and this allows a lighter deployment.
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.
After considering this and seeing that Pulp reads the static files on application startup, I've decided to drop the option to not generate these. I have moved it to its own class so it doesn't restart all applications if anything changes. Thinking about it, it should probably restart the API service if it reads the files.
README.md
Outdated
|
||
There is also `chunked_upload_dir` to configure the undocumented `CHUNKED_UPLOAD_DIR`. This directory stores the temporary files used for files uploaded as chunks. | ||
|
||
When the Apache vhost is managed, `apache_docroot` (default `/var/lib/pulp/docroot`) is also created. This doesn't contain any files, but this makes sure that there aren't any files being served. |
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 think there is some nuance of Apache embedded in this wording that makes it hard to know what this means. I can sum this up with: why do I care if files are being served or not?
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.
You should care that no files are served. Turns out that serving any files from Apache is a misconfiguration.
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.
Would another way to phrase this be:
Apache requires that a docroot be configured. By configuring this to an empty directory, we prevent Apache from being configured to accidentally server Pulp content outside of the Pulp content app?
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.
Yes, that is a much better way to phrase it.
I had some conversations with upstream. Right now I want to agree on the best layout and ensure we're not going to have to migrate twice. This PR has been very useful for me to get my thoughts straight, but moving back to a draft for now. |
@ekohl @jlsherrill how immediate is the need to get this straightened out? Should I close out theforeman/foreman-installer#543 , theforeman/puppet-foreman_proxy_content#275 , and #113 while we settle on a definitive layout? Or is it better to move forward with those while this one is still in progress ? |
pulp/pulpcore#799 (comment) would be roughly the migration plan. We can do the same in a Puppet will take care of the config update + application restarts. The cleanup of the symlink should happen in a |
7c07797
to
f627859
Compare
4e12059
to
6c1f3cd
Compare
1667892
to
1fa9ca3
Compare
Updated. I now believe this is mostly ready. I'm going to work on an installer migration to migrate the content. |
1fa9ca3
to
dd7141c
Compare
Migration in theforeman/foreman-installer#583. |
Note to self: check SELinux context on |
dd7141c
to
b225183
Compare
This explicitly sets the all directories and documents the layout. It diverges from the upstream defaults in that MEDIA_ROOT is set to a subdirectory and the directory permissions are stricter than upstream. Upstream this layout is proposed as the default. https://pulp.plan.io/issues/7178 has been opened for that.
b225183
to
4096989
Compare
@@ -11,6 +11,6 @@ | |||
pulpcore::admin { 'collectstatic --noinput': | |||
refreshonly => true, | |||
subscribe => Concat['pulpcore settings'], | |||
require => File[$pulpcore::pulp_static_root], | |||
require => File[$pulpcore::static_root], |
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.
require => File[$pulpcore::static_root], | |
subscribe => File[$pulpcore::static_root], |
As discussed on IRC, there is a very small possibility that owner/group could be changed. In that case we would want to re-run collectstatic so that the collected static content will also be changed to match.
In most regular use cases that is unlikely to happen, but that also means the cost of making this change (in terms of execution time) is negligible since the refresh would only get triggered in that edge case.
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.
This worked well in my testing
This explicitly sets the all directories and documents the layout. It diverges from the upstream defaults in that MEDIA_ROOT is set to a subdirectory and the directory permissions are stricter than upstream. The assets are served in static since this works around some SELinux issue.
Upstream this layout is proposed as the default. https://pulp.plan.io/issues/7178 has been opened for that.
It's an alternative to #113. It will need a migration in the installer to move any generated content.