[Pulp-dev] CONTENT_HOST woes -- need input

[Mike DePaulo]

On Tue, Oct 29, 2019 at 11:40 AM Brian Bouterse <bmbouter at redhat.com> wrote:

>
>
> On Tue, Oct 29, 2019 at 11:37 AM Brian Bouterse <bmbouter at redhat.com>
> wrote:
>
>>
>>
>> On Tue, Oct 29, 2019 at 11:19 AM Brian Bouterse <bmbouter at redhat.com>
>> wrote:
>>
>>> A Distribution, e.g. FileDistribution
>>> <https://docs.pulpproject.org/en/3.0/nightly/restapi.html#operation/distributions_file_file_read>
>>> has a base_url (not base_path) which defaults to returning data with
>>> "relative" urls, e.g. "/pulp/content/foo/..."   If you set the
>>> CONTENT_HOST
>>> <https://docs.pulpproject.org/en/3.0/nightly/installation/configuration.html#content-host>
>>> setting to "https://example.com:1234" then Pulp will return absolute
>>> URLs e.g.   "https://example.com:1234/pulp/content/foo/..."
>>>
>>> Concerns with what we have currently:
>>>
>>> 1. plugins like pulp_docker require this CONTENT_HOST to be set, but
>>> others may not, so this setting could become a dividing line for plugins
>>> that want it set versus those that don't.
>>>
>>> 2. Clients are semantically unsure how to handle responses for one Pulp
>>> server versus another. This setting changes the client's responsibilities
>>> (relative vs absolute URL handling).
>>>
>>> 3. Relative urls are not as usable as absolute urls.
>>>
>>>
>>> # Option 1: Remove the setting and have plugins handle it
>>> My concern with this option is that it's no easier to deal with
>>> plugin-by-plugin
>>>
>>> # Option 2: Keep the setting and make it a required (absolute URLs
>>> always)
>>> Users would always have to be involved, but installer could get it
>>> right. RPM packages could not though since they don't know about
>>> multi-machine installs.
>>>
>> This is seeming more and more the only way to know if you want HTTP/HTTPS
> versus FQDN/localhost
>
>>
>>> # Option 3: Option 2 + a default of FQDN
>>> This would align with a default that serves Pulp publically to
>>> non-localhost environments.
>>>
>> I realized we would have to pick HTTP or HTTPS here. :(
>

This is my preference for both Pulp project and its users. It provides the
simplest path to adding a new plugin; many users will not need to
reconfigure the pulp-wide settings.
(And admins are always responsible for their system-reported FQDN being
resolvable.)

I must still register my objections vs #1 though; in hopes that any
technical improvements can be identified (see bottom of email.)


>
>>> # Option 4: Option 2 + a default of FQDN
>>> This would align with a default that serves Pulp via localhost only
>>>
>> correction, Option 4 is for a default of 'localhost'
>>
> I realized we would have to pick HTTP or HTTPS here. :(
>
>>
>>
>>> # Any of the ^ options only consolidating CONTENT_PATH_PREFIX
>>> <https://docs.pulpproject.org/en/3.0/nightly/installation/configuration.html#content-path-prefix>
>>> Is this simpler?
>>>
>>>
>>> What would best serve your plugin? What would best serve Pulp users?
>>>
>>> Thanks!
>>> Brian
>>>
>>
I've only spent significant time co-mangaging 1 HA website (with multiple
web servers & multiple load balancers) in 1 conventional ("pets, not
cattle") IT environment, not as much experience as others. But I know that
any particular hostname or HTTP/HTTPS in CONTENT_HOST would complicate
administration/testing/debugging and possibly monitoring.

Hostname: Each servers' FQDN can be internal (organization's intranet
accessible) only and that's how you'll often access individual
servers yourself (or monitor the individual servers with a monitoring
solution, separate from the load balancer). However, users (internal or
external) will always access it via the load-balancer provided FQDN, so
that's what will be in your config.

HTTP/HTTPS: The webservers may not use SSL at all. SSL can be provided by
the load-balancers. So HTTP vs HTTPS is also a complication.

-Mike

-- 

Mike DePaulo

He / Him / His

Service Reliability Engineer, Pulp

Red Hat <https://www.redhat.com/>

IM: mikedep333

GPG: 51745404
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20191029/9c638077/attachment.htm>