<div dir="ltr"><div dir="ltr"><div>During the demo yesterday it was pointed out that 'cache_only' doesn't make sense as a name anymore since Pulp itself isn't doing the caching. Here's an issue to rename it with some naming suggestions:</div><div><br></div><div><a href="https://pulp.plan.io/issues/4243">https://pulp.plan.io/issues/4243</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 6, 2018 at 3:26 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I've heard a lot of positive feedback on this idea and no objections. I made this story tracking this threads proposal specifically [0] and I made it a subtask of the lazy epic [1]. My next step to finish the streamer is to work on [0] so I've taken that as assigned. I'll reply to the list when the next round of PRs are posted and passing in Travis. Hopefully that should complete most of the work for the lazy epic [1].<br></div><div><br></div><div>[0]: <a href="https://pulp.plan.io/issues/4239" target="_blank">https://pulp.plan.io/issues/4239</a><br></div><div>[1]: <a href="https://pulp.plan.io/issues/3693" target="_blank">https://pulp.plan.io/issues/3693</a><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 4:07 PM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Since no one is objecting, I'd like to see the PR[0] from @bmbouter finished up and merged soon. I am updating the pass-through cache story[1] to get it ready for implementation. I would like to remove all mention of separate content app and streamer from the description. <br></div><div><br></div><div><br></div><div>[0] <a href="https://github.com/pulp/pulp/pull/3779" target="_blank">https://github.com/pulp/pulp/pull/3779</a></div><div>[1] <a href="https://pulp.plan.io/issues/3894" target="_blank">https://pulp.plan.io/issues/3894</a><br> </div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 1:54 PM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>+1 to merge</div><div>+1 to have clear docs for plugin writers how to create their own content app<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 11:25 PM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It was pointed out on IRC that plugins that have to supply their own content app (such as docker) currently need to supply 2 implementations of it in order to support on-demand use cases. One using django and another using aiohttp. <br></div><div><br></div><div>We should not burden plugin writers in such a way. We really have to make the proposed change.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 3:24 PM Dana Walker <<a href="mailto:dawalker@redhat.com" target="_blank">dawalker@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>In light of the efficiency gains and lack of significant drawbacks, I'm +1 on this proposal.</div><div><br></div><div>--Dana</div><div><br></div><div><br></div><div><div><div dir="ltr" class="gmail-m_-8986381483678263155gmail-m_-116014493257330115m_8187491585123344877m_-8946211020608827926m_3367393050450332003gmail_signature"><div dir="ltr"><div> <p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>Dana</span> <span>Walker</span></p> <p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Associate Software Engineer</span><span style="font-weight:normal;color:rgb(170,170,170);margin:0px"></span></p> <p style="font-weight:normal;margin:0px;font-size:10px;color:rgb(153,153,153)"><a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span><br><br></span></a></p> <table border="0"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"> <img src="https://www.redhat.com/files/brand/email/sig-redhat.png" width="90" height="auto"></a> </td> </tr></tbody></table> </div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 2:40 PM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I like the idea of combining the two applications for all the reasons already outlined on this thread. The user experience is going to be simplified by this change. However, I want to point out that it will also alter the plugin writer experience. Plugin writers that want to have their own content app will now need to provide it as a plugin for the content app (which is not a Django project). We should be able to clearly document this for plugin writers. pulp_docker plugin will need to adopt this change. For that reason I'd like us to make a decision on this soon. <br></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" target="_blank">jortel@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div 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> _______________________________________________<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> </blockquote></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> _______________________________________________<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> _______________________________________________<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> </blockquote></div>