bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@wandisco.com>
Subject Re: Dogfooding multi product on i.a.o/bloodhound
Date Thu, 19 Feb 2015 08:58:46 GMT
On 18.02.2015 13:19, Gary Martin wrote:
>
> On 18/02/15 02:01, John Chambers wrote:
>> I have setup the new Bloodhound environment on the i.a.o vm. But like I
>> thought it is not accessable from the outside world.
>>
>> I will look at doing what Brane suggests and use apache rewrite rules
>> and
>> virtual host configurations to test the new setup before I migrate
>> the old
>> environment and data across.
>>
>> I am also going to look at providing a holding page so that I can
>> bring the
>> service down for maintenance in the future.
>>
>> I will keep you informed.
>>
>> Cheers
>>
>> John
>>
>> On 18 February 2015 at 01:04, Branko ─îibej <brane@wandisco.com> wrote:
>>
>>> On 17.02.2015 20:22, Gary Martin wrote:
>>>> On 17/02/15 14:28, John Chambers wrote:
>>>>
>>>> Incidentally, I think I specified the wrong redirect in my last
>>>> message as we use products rather than product so that redirect should
>>>> be:
>>>>
>>>> https://issues.apache.org/bloodhound =>
>>>> https://issues.apache.org/bhound/products/BLOODHOUND
>>>
>>> We can make the right redirects work without Infra involvement and
>>> without changing the root URL https://issues.apache.org/bloodhound so
>>> something horrible like .../bhound.
>>>
>>> All it takes is to have a careful look at the current set of URLs used
>>> for BH stuff and then writing a number of rewrite rules that will catch
>>> only those URLs, but not any new .../bloodhound/product URLs. If that
>>> means we invent a virtual location, e.g., .../bloodhound/main to refer
>>> to the global environment, that's fine, IMO. Better than the current
>>> proposal in any case.
>>>
>>> -- Brane
>>>
>
> I can understand the dislike of the suggested url. My suggestion came
> from an attempt to keep things relatively simple, albeit with INFRA
> involvement. It would also minimise the slightly strange situation of
> one product appearing to have some sort of special status.
>
> I take it that Brane is not suggesting that we redirect like this:
> /bloodhound/(?!main).* to /bloodhound/main/products/BLOODHOUND

My idea is to keep /bloodhound/products untouched, so the BH product
would appear there just like any other, and we'd of course change all
URLs in our docs to the new scheme. The reason to also expose that
product environment under /bloodhound is to make historical URLs (in
mails, tickets, etc) work; that'd be just a bit different than in other
BH deployments, but I wouldn't worry about that.

So the full proposal is:

  * /bloodhound/main exposes the global environment
  * /bloodhound/main/products (and similar weird combinations) are blocked
  * /bloodhound/products is treated as the regular product prefix
  * /bloodhound/** redirects to /bloodhound/products/BLOODHOUND/**
    (or whatever you want the product prefix to be)

By far the easiest way to do that is to map the WSGI to a virtual host
bound to localhost, then rewrite-proxy the externally visible vhost to
the real one. Though I'm not sure how that'll work with SSL and
authentication; depends on Bloodhound/trac's capabilities there. I
suspect we'd need at least 'ProxyPreserveHost on' in the configuration.

-- Brane

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message