Re: [Pulp-dev] Using Gunicorn and Static Files
I tested this method out and it did work with gunicorn. The only ugly part is having to re-define the MIDDLEWARE entirely. I couldn't find a way to simply just add the middleware I wanted in the spot I needed it. Brian any thoughts on supporting this out of the box? I'm happy to do the work but I'd like to know it's desired. On Tue, Oct 9, 2018 at 9:11 AM Patrick Creech wrote: > On Wed, 2018-10-03 at 16:28 -0400, Eric Helms wrote: > > Howdy, > > > > When switching a deployment over to use gunicorn, DEBUG = TRUE for > serving static files stopped working. I endeavored to follow the production > install method using collectstatic. This required > > setting STATIC_ROOT which appeared to not be set by default. > > > > 1) Is there a default value for STATIC_ROOT I can set for collectstatic? > > 2) Can gunicorn serve these static files for me? > > > > I realize the documentation calls for serving static files via a > webserver like nginx or Apache. However, that becomes a bit overkill in > something like a container deployment. If I run a separate > > webserver, then I would run it as a separate container and have to mount > the static files volume. This felt like overkill to me to have a persistent > volume to store and mount static files instead of > > the application server providing them for the application. > > > > Any thoughts and help are appreciated. > > > > Eric > > Eric, > > I got curious and took a look into your situation. > > I came across this project, suggested to be used by heroku, to achieve the > goal you are working towards: http://whitenoise.evans.io/en/stable/ > > It comes with django middleware support out of the box, so all you would > need to do is to 'pip install whietnoise' and edit the MIDDLEWARE > collection in the settings.py to include it, You want it to > load AFTER SecurityMiddleware, but BEFORE everything else, so make it the > second line, here: > https://github.com/pulp/pulp/blob/master/pulpcore/pulpcore/app/settings.py#L91 > > For your deployment model, it shouldn't be hard to apply a patch to the > code at a stage in your container process to inject this middleware into > the settings.py > > Otherwise, it's the standard 'staticfiles' process for django, They have > it simplified in step 1 here: > http://whitenoise.evans.io/en/stable/django.html > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Changeset code in Pulp 3
As part of the upcoming RC release, there was a question as to whether the Changeset code could removed. AFAIK, there is only one plugin still using it (pulp_ansible) although there’s a ticket to update it to use the Stages code. I wanted to ask though if we were planning to keep the Changeset code in Pulp 3? David ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Call for Presenters: Community Demo, Wednesday October 17th
Have you contributed to Pulp or the Pulp community in some way since the last community demo? Show the community what you've done! The next community demo is scheduled for Wednesday, October 17 at 14:00 UTC [0]. All demos should be pre-recorded; here are some docs on how to do that [1]. Once you have your topic selected, put yourself on the agenda here [2]. [0]: https://bit.ly/2CbaO94 [1]: https://pulp.plan.io/projects/pulp/wiki/Demo_Presenter_Notes [2]: https://etherpad.net/p/Pulp_Community_Demo_Agenda Thanks, Brian ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] To integrate Fus or not to....
One consideration is that whatever we do for Pulp 2, we’ll have to do again in Pulp 3. For that reason, as ugly as it is, I am leaning toward calling to Fus via a pipe. It seems the easiest, least amount of work, and most reusable. David On Wed, Oct 10, 2018 at 10:00 AM Milan Kovacik wrote: > ...that might be the question we should ask ourselves once again when it > comes to recursive copying of units between repositories. > > I'd like to poll folks opinions about the possibilities that we may have > when it comes to integrating third party solvers in Pulp. My yesterday's > chat with the #fedora-modularity folks about us integrating the Fus[1] > solver in order to reuse the Fus algorithm ran into a couple of bumps: > > * it would be laborous to create a programmatic Python API between Fus and > Pulp because we can't directly use the libsolv thingies (pools, solvables > and friends) in such an API because Fus is written utilizing GObject, which > is incompatible with Swig, which in turn is used in libsolv to expose the > python bindings. One would have to either re-wrap libsolv code in Fus to > work with pygobject or submit PRs against libsolv to support GObject > introspection. I dunno the details of either approach (yet) but from the > sad faces on the IRC and the Fus PR[1] it seemed like a lot of work but > it's still an option > > * we still should be able to integrate thru a pipe into Fus, that would > make it possible to dump modular and ursine metadata into Fus to perform > the dependency solving in a separate subprocess. We should probably > re-check the reasons behind our previous decision not to do the same with > DNF[2]. > > * we should be able to extend current libsolv solver in Pulp, > reimplementing the algorithm from Fus. This might be as laborous as the > first option. It would probably give us more flexibility as well as more > room for screwing things up but the responsibility would be ours alone. > > Please let me know what option seems more appealing to you; other option > suggestion are welcome too. > > Cheers, > milan > > [1] https://github.com/fedora-modularity/fus/pull/46 > [2] https://pulp.plan.io/issues/3528#note-7 > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] To integrate Fus or not to....
...that might be the question we should ask ourselves once again when it comes to recursive copying of units between repositories. I'd like to poll folks opinions about the possibilities that we may have when it comes to integrating third party solvers in Pulp. My yesterday's chat with the #fedora-modularity folks about us integrating the Fus[1] solver in order to reuse the Fus algorithm ran into a couple of bumps: * it would be laborous to create a programmatic Python API between Fus and Pulp because we can't directly use the libsolv thingies (pools, solvables and friends) in such an API because Fus is written utilizing GObject, which is incompatible with Swig, which in turn is used in libsolv to expose the python bindings. One would have to either re-wrap libsolv code in Fus to work with pygobject or submit PRs against libsolv to support GObject introspection. I dunno the details of either approach (yet) but from the sad faces on the IRC and the Fus PR[1] it seemed like a lot of work but it's still an option * we still should be able to integrate thru a pipe into Fus, that would make it possible to dump modular and ursine metadata into Fus to perform the dependency solving in a separate subprocess. We should probably re-check the reasons behind our previous decision not to do the same with DNF[2]. * we should be able to extend current libsolv solver in Pulp, reimplementing the algorithm from Fus. This might be as laborous as the first option. It would probably give us more flexibility as well as more room for screwing things up but the responsibility would be ours alone. Please let me know what option seems more appealing to you; other option suggestion are welcome too. Cheers, milan [1] https://github.com/fedora-modularity/fus/pull/46 [2] https://pulp.plan.io/issues/3528#note-7 ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
