<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><br></div><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.<br></div><div><br></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><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 3:13 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The REST API app should reasonably facilitate being scoped to a base path. There just isn't a need for a REST API to own the entire path space for an endpoint (host + port). And it's common to define multiple vhosts on the same endpoint, serving different APIs at different paths as we've seen with Pulp 2.<div><br></div><div>Content serving is another story and is a better fit for owning all of its path space. We want the ability to tell a user the full URL to their published repo. That's harder to do if there's a base path controlled by the deployer, but not impossible. And when letting a user specify a path where they want a publication to be available (distributed), should they include that base path? Or not? If they do, should Pulp validate that the specified path falls within whatever base path the content app is deployed at? There's no rocket science here, but it does add complexity and potential for user confusion.</div><div><br></div><div>An app like crane can be a special case. Any implementation of the docker registry needs to own a specific bit of base path ("/v2"), or else it won't work at all. (a great example of why our REST API should be compatible with custom base paths) What if some other content type also needed that path space? This is why crane, and the normal upstream docker registry, are typically run on a separate port from anything else. It's hard to generalize this problem. We could accommodate content types that "play nice" by giving them path space for APIs in the content serving app, but then we're back to some of the same problems of needing to track that path space vs. the path space available to Distributions. It's simpler to let these apps exist on one or more separate endpoints, but I see the value in looking for opportunities to reduce that need.</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 10:35 AM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wont this mean users cannot run pulp as part of a stack .. like in Satellite?  What about the Katello API?<br>
<div class="m_-4214016723403061625HOEnZb"><div class="m_-4214016723403061625h5"><br>
On 11/02/2017 04:19 PM, Brian Bouterse wrote:<br>
> We're looking at developing apache/nginx scripts, and I was thinking about documenting the webserver<br>
> requirements. I think Pulp probably has to be rooted at / on any given site so that it can host live APIs.<br>
> Users can still vhost multiple sites at other hostnames so I think it's ok, but I'm interested in what others<br>
> think. I wrote this up here [0] for some discussion on the issue.<br>
><br>
> [0]: <a href="https://pulp.plan.io/issues/3114" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/31<wbr>14</a><br>
><br>
> -Brian<br>
><br>
><br>
</div></div><div class="m_-4214016723403061625HOEnZb"><div class="m_-4214016723403061625h5">> ______________________________<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>
<br>
</div></div><br>______________________________<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></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-4214016723403061625gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">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!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>