[Pulp-dev] Webserver owning the entire url namespace?

Brian Bouterse bbouters at redhat.com
Mon Nov 6 14:34:28 UTC 2017

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.

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.

So we want to simplify the common cases and allow for complex cases to
still work. To me that is:

* 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.
* Recommend that Pulp be run not scoped to a base path (simplest). If users
follow this recommendation 100% of their live APIs will work.

Then for allowing scoping Pulp to a base path:

* 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.
* Users will need to figure out to make the live APIs work. That's really
between plugin writers and users at that point.

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.

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).

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 /.

On Fri, Nov 3, 2017 at 3:13 PM, Michael Hrivnak <mhrivnak at redhat.com> wrote:

> 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.
> 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.
> 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.
> On Fri, Nov 3, 2017 at 10:35 AM, Jeff Ortel <jortel at redhat.com> wrote:
>> Wont this mean users cannot run pulp as part of a stack .. like in
>> Satellite?  What about the Katello API?
>> On 11/02/2017 04:19 PM, Brian Bouterse wrote:
>> > We're looking at developing apache/nginx scripts, and I was thinking
>> about documenting the webserver
>> > requirements. I think Pulp probably has to be rooted at / on any given
>> site so that it can host live APIs.
>> > Users can still vhost multiple sites at other hostnames so I think it's
>> ok, but I'm interested in what others
>> > think. I wrote this up here [0] for some discussion on the issue.
>> >
>> > [0]: https://pulp.plan.io/issues/3114
>> >
>> > -Brian
>> >
>> >
>> > _______________________________________________
>> > Pulp-dev mailing list
>> > Pulp-dev at redhat.com
>> > https://www.redhat.com/mailman/listinfo/pulp-dev
>> >
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
> --
> Michael Hrivnak
> Principal Software Engineer, RHCE
> Red Hat
> _______________________________________________
> 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/20171106/a86fab4e/attachment.htm>

More information about the Pulp-dev mailing list