<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Jeff mentioned this to me yesterday, and this decision greatly affects the remaining work of the streamer. Jeff and I thought a prototype also would be easy and help make the idea more concrete. Here is some code you can try with this idea. This prototype took about an hour, so we can throw it away or delete it if we want.<br></div><div><br></div><div>This is the gist of the pulpcore changes (no docs or travis updates): <a href="https://github.com/pulp/pulp/pull/3779">https://github.com/pulp/pulp/pull/3779</a></div><div>Use this branch of the streamer (updated for settings changes from ^):  <a href="https://github.com/bmbouter/pulp_streamer/tree/streamer-replaces-content-app">https://github.com/bmbouter/pulp_streamer/tree/streamer-replaces-content-app</a></div><div><br></div><div>In addition to the great benefits Jeff outlined, in my testing I can see the aiohttp based streamer is generally a lot faster in handling requests than Django which could be big for our performance. Also, it simplifies the settings greatly since we don't need redirect configs anymore (see the PR).<br></div><div><br></div><div>More thoughts would be great. The lazy work is blocked until we're able to pick a direction here.</div><div><br></div><div>Thanks!<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 4:59 PM Jeff Ortel <<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <u>BACKGROUND</u><br>
    <br>
    The pulp3 content app and the streamer (in-progress) currently have
    a lot of duplicate code and functionality.  At the very least, I
    think there is a opportunity to refactor both and share code.  But,
    this would leave us with two components with significant overlap in
    functionality.  <br>
    <br>
    The functionality exclusive to the content-app:<br>
      - Optionally delegate file serving to a web server. (Eg:
    mod_xsendfile).<br>
      - Optional redirect to the streamer.<br>
    <br>
    The functionality exclusive to the streamer:<br>
      - Using the Remote & RemoteArtifact to download the file and
    stream on demand.<br>
    <br>
    Not much difference which raises the question: "Why do we have
    both?"  I think the answer may be that we don't.<br>
    <br>
    <u>PROPOSAL</u><br>
    <br>
    Let's pull the content-app out and merge it with the streamer.  The
    new content (app) would have <i>streamer</i> architecture &
    functionality.  When a requested artifact has not been downloaded,
    it would download/streamed instead of REDIRECT.  This does mean that
    deployments and development environments would need to run an
    additional service to serve content.  The /pulp/content endpoint
    would be on a different port than the API.  I see this separation as
    a healthy thing.  There is significant efficiency to be gained as
    well.  Let's start with eliminating the REDIRECTs.  Cutting the GET
    requests in half is a win for both the client, the network and the
    Pulp web stack.  Next is database queries.  Since both applications
    needed to perform many of the same queries, combining the
    applications will roughly cut them in half as well.  Since the
    streamer is based on asyncio and so would the merged app.<br>
    <br>
    There are probably lots of other pros/cons I have not considered but
    it seems relatively straight forward.<br>
    <br>
    I'm thinking the new content app/service would be named: <i>pulp-content</i>.<br>
    <br>
    Thoughts?<br>
    <br>
  </div>

_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>