[Pulp-dev] pulp3: Publishing Proposal

Brian Bouterse bbouters at redhat.com
Thu Jun 29 21:17:44 UTC 2017

+100 to this proposal as I understand it. Having a redirect engine to serve
100% of content that is looked up via the db is a must-have for pulp3.
Besides opening up object storage use cases, solving practical file system
limits with symlinks, it will allow us to reorganize content on the backend
without any interruption of service while serving that content. To describe
that pain-point another way, moving the location of a unit *and* fixing all
of the symlinks to that unit while Pulp is online is a PITA and maybe not
even possible.

Also a big +1 to treating an "export to disk or a remote system for
something other than Pulp to serve" as a dedicated, separate use case. I
think we could get away without doing that in the MVP but maybe others
think it should be in the MVP.

In the proposal it said that we only deliver content using XSendFile. We
need a base implementation of this content serving that does not require
the xSendFile. Specifically Pulp should carry a "let me serve that content
for you inefficiently using Django" implementation so that developer
environments can be fully functional without a webserver that has
modXSendFile. The XSendFile integration should be an option feature. It
should default to off, and it should be required for the MVP.

Also what about content protection? Are we going to use redirects with
time-bombed urls? Or are we expecting the cert verification to occur twice
(once for the initial request, and again to follow the 301 redirect)?

I also want to make a similar point here about carrying a content
protection feature in Pulp and not relying on Apache exclusively for it. As
a developer I should be able to have the same content protection features
with runserver as you do with Apache so that developer environment are
fully functional with runserver.


On Thu, Jun 29, 2017 at 12:05 PM, Jeff Ortel <jortel at redhat.com> wrote:

> Another aspect I'm considering is pulp serving a single publication with
> multiple and/or limited protocols
> (schemes).  This pertains to supporting both HTTP and HTTPS or limiting to
> only HTTPS.  As proposed, I think
> we get both HTTP and HTTPS for free but don't yet have a way for the
> content app to only support HTTPS.
> Would adding something like:
>   (bool) http_enabled
>   (bool) https_enabled
> to the Publisher and Publication make sense?
> Like auth, the settings could be set on the Publication by the plugin API
> when it get's created.  The content
> app could check this and 404 as appropriate.
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170629/71b7014c/attachment.htm>

More information about the Pulp-dev mailing list