<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 8, 2017 at 11:05 AM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:<br><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"><span>Please see my comments inline.</span><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Nov 7, 2017 at 3:28 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349m_4093078810622157849gmail-">On Mon, Nov 6, 2017 at 9:34 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><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>Yes the REST API can be scoped to a base path. Pulp can also serve content even if its scoped to a base path. So Pulp itself will work great even if scoped to a base path.<br></div><div><br></div><div>The issue is 100% around the "content serving apps" like Crane, Forge, etc. I call those things "live content APIs". The current plan AIUI is that "live content APIs" will be satisfied using a custom viewset so the plugin developer does not need to package+ship+version+configure a separate app, e.g. crane, forge, etc.</div></div></blockquote><div><br></div></span><div>That may work in some cases, but I don't think it's a good fit for cases like the docker registry API.</div><div><br></div><div>The registry API has enough path complexity that a viewset would not be sufficient, so it would need to provide a mix of routers and viewsets. It's an entire app worth of routes and views, including its own auth and search. DRF is not a great tool for that job, and it's valuable to enable plugin writers to use whatever tools/frameworks/languages make sense. For example, right now there is an effort underway to replace crane with an app that uses the "docker distribution" code to serve the API, but can still read crane's data files and serve Pulp publications. That level of flexibility is important.</div></div></div></div></blockquote><div><br></div></span><span><div>I believe you are suggesting that a Pulp backend could be built for a 
Docker registry. This backend would know how to consume information 
about docker content published by Pulp. This would indeed be a separate 
application. However, until such a registry backend exists, it would be 
good to allow the Docker plugin authors to provide a docker API as part 
of the same application. </div></span></div></div></div></blockquote><div><br></div><div>I think you're describing crane as it exists today. Just looking at crane itself, I don't think it makes sense to rewrite it using DRF. Even if we had to start from scratch for some reason, I don't think DRF would make sense. Crane doesn't use django (nor is django obviously the best fit), it doesn't use a database at all, it isn't particularly RESTful, etc. Today crane is implemented using flask, which meets its needs well. We would probably benefit logistically from converting it to a django app, just to reduce the number of frameworks we need to keep up with, but I'm not aware of any other reason to do so.</div><div><br></div><div>With my comment in the previous email, I was only trying to point out that someone is trying to re-implement crane using yet a different technology stack, even more different from DRF than flask is.</div><div> </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 class="gmail_extra"><div class="gmail_quote"><span><div> </div><div><br></div></span><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 class="gmail_extra"><div class="gmail_quote"><div><br></div><span><div>From a deployment perspective, it's been a key use case to deploy crane at the perimeter, rsync published image files out to a file or CDN service, and run the rest of Pulp on a well-protected internal network.</div></span></div></div></div></blockquote><div><br></div><span><div>Pulp can also be installed at the perimeter. Core should support a 
setting that enables/disables the REST API. Each plugin could support a 
setting that enables/disables its content API.</div></span></div></div></div></blockquote><div><br></div><div>I think we're envisioning a similar goal, but with a different mechanism. I like the idea of a user selecting which components should be active. Making each component a WSGI app is very easy for us and very convenient for users. You can see Pulp 2's WSGI apps defined here:</div><div><br></div><div><a href="https://github.com/pulp/pulp/tree/master/server/usr/share/pulp/wsgi">https://github.com/pulp/pulp/tree/master/server/usr/share/pulp/wsgi</a><br></div><div><br></div><div>Depending on whether a user wants to run each component embedded in normal httpd processes, or in separate daemon processes, it's just a matter of enabling or not a small httpd config file like this one:</div><div><br></div><div><a href="https://github.com/pulp/pulp/blob/master/server/etc/httpd/conf.d/pulp_content.conf">https://github.com/pulp/pulp/blob/master/server/etc/httpd/conf.d/pulp_content.conf</a><br></div><div><br></div><div>This gives the most flexibility. A user won't need to deploy the entire stack of Pulp dependencies with all of their plugins at the perimeter if they don't want to; we can choose to deliver each WSGI app separately, or not, depending on what is convenient.</div><div><br></div><div>This separation has worked very well in Pulp 2, and as far as I know there have been no complaints about it.</div><div> </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 class="gmail_extra"><div class="gmail_quote"><span><div> </div><div> </div></span><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 class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349m_4093078810622157849gmail-"><div> <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><br></div><span><div>So we want to simplify the common cases and allow for complex cases to still work. To me that is:</div><div><br></div><div>* allow plugin developers to deliver live content APIs in the form of viewsets. They are free to root them anywhere in the url namespace they want to. Their requirements require that.</div><div>* Recommend that Pulp be run not scoped to a base path (simplest). If users follow this recommendation 100% of their live APIs will work.</div><div><br></div><div>Then for allowing scoping Pulp to a base path:</div><div><br></div><div>* Pulp can be scoped to a base path and it will work without any extra config. The docs should state this is possible, but that "live APIs" may not work.<br></div><div>* Users will need to figure out to make the live APIs work. That's really between plugin writers and users at that point.</div><div><br></div><div>Note that currently one WSGI process is serving both the REST API, the Content APIs, and the "live content APIs". I don't see a use case to separate them at this point. If there is a believe that (a) we will have more than 1 WSGI process and (b) why, please share those thoughts.</div></span></div></blockquote><div><br></div></span><span><div>We should definitely keep the REST API separate from content serving, as it is in Pulp 2. They are very different services with different goals, needs and characteristics. The streamer is a third independent service that likely makes sense to keep separate.</div><div><br></div><div>The REST API and content apps have different resource needs. Content serving can use read-only access to a DB and filesystem, and it does not need message broker access. We could probably get away with only giving it access to a few tables in the DB. It does not need access to much of the config or secrets that the REST API needs. The REST API app probably needs a lot more memory and CPU than the content app.</div><div><br></div><div>They have different audience/access needs also. A small group of humans and/or automation need to infrequently use the REST API to manage what content Pulp makes available. A much larger audience of content consumers needs to access publications. The two audiences often exist on different networks. More downtime can be tolerated from the REST API than the content app.</div><div><br></div><div>Related to the access differences, the two apps have different scalability needs. The amount of traffic likely to be handled by the REST API vs content app are very different. And on the uptime issue, we definitely have a use case for continuing to serve publications while Pulp is being upgraded or is otherwise down for maintenance.<br></div><div><br></div><div>All of that said, there's no reason why a user couldn't use a web server like httpd to run all three WSGI apps in the same process, multiplied across its normal pool of processes. We should make the apps available as separate WSGI apps, and users can deploy them in whatever combinations meet their needs. </div></span></div></div></div></blockquote><div><br></div><span><div><span class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349m_4093078810622157849gmail-im"><div><br></div></span><div>As
 mentioned above, Pulp should use configuration settings to disable and 
enable the REST API and the individual content APIs. Separate WSGI 
applications makes the deployment process more complicated.</div></div><div> </div></span><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 class="gmail_extra"><div class="gmail_quote"><div><br></div><span><div>For example, Pulp 2 defaults to running the REST API as a separate set of daemon processes within httpd (see WSGIDaemonProcess for details) to isolate them from the rest of the httpd processes, which serve content (and potentially other apps like katello).</div><span class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349m_4093078810622157849gmail-"><div> </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></div><div><br></div><div>In
 Pulp2 we matched on /api/v2/ and maybe /content/ and just those two 
urls. This required plugin developres who need live APIs (docker, 
puppet, etc) to ship a separate application (crane, forget, etc).</div><div><br></div>There
 is a middleground where we recommend Pulp run from / but they can bury 
it deeper in the url structure if they want, but their stuff may not 
work. Overall though, if we are bundling live APIs a plugin viewsets 
then I don't see how it will work if we don't recommend owning /.</div></blockquote><div><br></div></span><div>If we advocate that plugin writers add endpoints somewhere to support type-specific content access APIs, that should go in the content-serving app. It's important that such APIs only serve content that is part of an active publication, which is a role well-matched to the content app. The access, scalability and reliability needs are also a match.</div></span></div></div></div></blockquote><div><br></div><span><div><span class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349m_4093078810622157849gmail-im"><div><br></div></span><div>I don't see that there is a real difference in these needs. Pulp should be scalable and reliable. </div> </div></span><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 class="gmail_extra"><div class="gmail_quote"><div><br></div><span><div>A challenge with that pattern is tracking what path space is claimed by a plugin's live API, and making sure other Distributions don't use that path space. I'm sure that could be done, but it adds complexity that's worth thinking through.</div></span></div><span><span class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349m_4093078810622157849gmail-"><div><br></div>-- <br><div class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349m_4093078810622157849gmail-m_3990032913088528539gmail-m_6504918861677906868gmail-m_832761957120915607gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Michael</span> <span style="margin:0px;padding:0px">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Principal Software Engineer</span><span style="margin:0px;padding:0px">, <span style="margin:0px;padding:0px">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px">Red Hat</p></div></div>
</span></span></div></div>
<br><span>______________________________<wbr>_________________<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<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-3631091789903155413m_5860473270712828472m_-8655594943162793349gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Michael</span> <span style="margin:0px;padding:0px">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Principal Software Engineer</span><span style="margin:0px;padding:0px">, <span style="margin:0px;padding:0px">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px">Red Hat</p></div></div>
</div></div>