You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by John Chambers <ch...@apache.org> on 2015/01/26 22:03:17 UTC
Dogfooding multi product on i.a.o/bloodhound
As some of you may know I have recently taken an interest in the
infrastructure side of the project.
The following have be highlighted to me as the main priorities at the
moment:
1. Ensuring the demo servers are online.
2. Re-enabling source browsing
3. Upgrading i.a.o to version 0.8 from 0.4
4. Dealing with spam tickets.
5. Dealing with robot users.
6. Setup multi product on i.a.o.
I know there will be issues migrating tickets from a single to multi
product setup so I am proposing to create a new installation of bloodhound
at version 0.8 that will have multiple products defined. Migrating the wiki
content but leave the majority of the tickets in the old instance. Which
will still be available for reference.
We can then start afresh in a multi product setup. The new instance will
have all the relevant plugins to prevent spam / robot users etc. And will
be easier to maintain and upgrade.
Let me know what you think.
Cheers
John.
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Branko Čibej <br...@wandisco.com>.
On 17.02.2015 00:45, Olemis Lang wrote:
> On 2/16/15, Branko Čibej <br...@wandisco.com> wrote:
>> To maintain URL compatibility,
>> we can design rewrite rules for the Apache config that make all
>> product-scoped tickets, pages, etc. visible at their old locations.
>>
> HTTP 301 , isn't it ?
Most likely, yes. There are several options:
* Issue a permanent redirect (301); this will tell browsers to always
look at the target URL in future.
* Issue a temporary redirect (302, or 307; have to check specs);
browsers will keep hitting the old URL and be redirected.
* Do URL rewrite magic internally, so that the request URL is remapped
to the new locations by HTTPd itself. This avoids the roundtrip in
the temp-redirect case and still allows us to harmlessly change the
mapping and/or URL prefixes in future.
IMO, 301 is just fine, as long as we're really careful to make sure that
we get all redirects right on the first go.
-- Brane
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Olemis Lang <ol...@gmail.com>.
On 2/16/15, Branko Čibej <br...@wandisco.com> wrote:
> On 16.02.2015 16:25, Olemis Lang wrote:
>
[...]
>>> The options I can think of are:
>>>
>>> 1. Change the setup so that we are using the default product to serve
>>> all
>>> the pages.
>>> 2. Create a new StartWiki page to allow the users to select the product
>>> they want to work with.
>>>
>> Considering the answers to questions above I might have another
>> proposal ... which is basically to continue hosting the default
>> product at i.a.o/bh other potential new products at
>> i.a.o/bh/products/PREFIX and global admin at some other
>> non-conflicting URL e.g. i.a.o/bh/global (<= but may a different
>> naming convention be chosen as well)
>
>
> I'd really hate having BH tickets etc. in the default product.
JFTR , the default product is just like any other regular product .
Indeed you can run a BH instance and never care about default product
at all .
OTOH by reviewing the code I found this .
{{{#!py
default_product_prefix = Option(
'multiproduct',
'default_product_prefix',
default='@',
doc="""Prefix used for default product when migrating single-product
installations to multi-product.""", doc_domain='multiproduct')
}}}
@John , this makes me think that legacy resources should be imported
into BH product if the following option is set in trac.ini prior to DB
upgrade .
{{{#!ini
[multiproduct]
default_product_prefix = BH
}}}
N.B There is a similar option [ticket] default_product , but it is not
related to the install procedure . Besides I think I should clarify
that the *global* environment is indeed different to any other product
e.g. it supports plugin install , global site admin ...
> They
> should be in the BH/bloodhound product.
I agree . In my previous message I was only talking about
"URL-to-environment mapping" .
> To maintain URL compatibility,
> we can design rewrite rules for the Apache config that make all
> product-scoped tickets, pages, etc. visible at their old locations.
>
HTTP 301 , isn't it ?
> The reason why it makes sense to scope all BH stuff into its own product
> is that it will then be easier for other projects to adopt BH as their
> issue tracker.
+1
p.s. Now that I take a look it seems that BH=0.4 does not have some MP
changes in product tables at all . I was wrong in my previous message
, sorry .
--
Regards,
Olemis - @olemislc
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Ryan J Ollos <rj...@apache.org>.
On Wed, Feb 18, 2015 at 12:37 PM, John Chambers <ch...@apache.org> wrote:
> I have just restored the database from a backup I had taken on Thursday
> 15th February.
>
> This appears to have sorted out the start page issue. But i would be
> grateful if others with more knowledge of the system could take a look.
> I don't believe there has been any changes to tickets etc. But again if you
> know of any changes they may need to be reapplied.
>
> Now I must say sorry. It appears that last night when setting up the new
> Bloodhound environment I used the wrong database. I will try not to make
> the same mistake again.
>
No problem, I'm known to do similar things. Thanks for fixing so quickly.
Everything looks good to me.
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
I have just restored the database from a backup I had taken on Thursday
15th February.
This appears to have sorted out the start page issue. But i would be
grateful if others with more knowledge of the system could take a look.
I don't believe there has been any changes to tickets etc. But again if you
know of any changes they may need to be reapplied.
Now I must say sorry. It appears that last night when setting up the new
Bloodhound environment I used the wrong database. I will try not to make
the same mistake again.
Cheers
John
On 18 February 2015 at 16:26, Ryan J Ollos <rj...@apache.org> wrote:
> On Tue, Feb 17, 2015 at 5:04 PM, Branko Čibej <br...@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.
> >
>
> Yeah, everything else sounds fine to me, but I also hope we can avoid
> "bhound" in the URL.
>
>
> > 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
> >
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Ryan J Ollos <rj...@apache.org>.
On Tue, Feb 17, 2015 at 5:04 PM, Branko Čibej <br...@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.
>
Yeah, everything else sounds fine to me, but I also hope we can avoid
"bhound" in the URL.
> 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
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
I think we might be getting ahead of ourselves by expecting INFRA to take
over the running of this Bloodhound instance. I would expect that to happen
only after other projects started to use bloodhound for their issue
tracking and wiki.
However this is the instance we use for dogfooding and so I think that I
should be concentrating on getting a working version of bloodhound 0.8.0
with all the tickets and attachments and external links working as they do
now. But as part of a multi product installation.
I think involving INFRA at this stage could be counter productive because
they may ask for more than I am able to give at the present time.
I don't know enough about managing an instance of Bloodhound to answer your
question about the redirect Gary. Maybe we need the involvement of the
developers who implemented multi product to explain further.
Like I said previously my next step is to install a separate instance of
Bloodhound 0.8.0 on the server to see if we can access it externally
without any changes by INFRA. If that works then I will migrate the
existing tickets etc and setup the redirect so hopefully we can continue to
use the system as is.
Cheers
John.
On 17 Feb 2015 19:22, "Gary Martin" <gj...@apache.org> wrote:
> On 17/02/15 14:28, John Chambers wrote:
>
>> Ok I think we have a plan. Now I just need to figure out how to implement
>> it ;)
>>
>> The only thing is I think I am going to have to involve INFRA because I
>> think the only way into our VM is via https://issues.apache.org/
>> bloodhound
>> and I don't think making any config changes to the Apache2 config on the
>> vm
>> will allow external access via another url i.e
>> https://issues.apache.org/bhound.
>>
>> I am going to try and test this by installing a new instance of bloodhound
>> 0.8.0 on the VM and try and access it via the above url. If this is not
>> possible I will raise this with INFRA. They may also be the ones who can
>> setup the redirect from https://issues.apache.org/bloodhound to
>> https://issues.apache.org/bhound/product/BLOODHOUND
>>
>> I will keep you informed.
>>
>> Cheers
>>
>> John
>>
>
> Yes, it is probably wise to talk with INFRA about this to figure out what
> they need to do. With our assumption that they will eventually take control
> of the running, they might wish to assert their preference instead. I don't
> think we need to be overly attached to a particular path.
>
> 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
>
> So, has anyone got any problems with this part of the plan? Is there
> anything that anyone thinks will come back to haunt us?
>
> Cheers,
> Gary
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Gary Martin <gj...@apache.org>.
On 18/02/15 13:07, John Chambers wrote:
> Hmm not sure what has happened to the start page. I will take a look later
> when I get home.
>
> I am still a little unclear on the redirects we need. I assumed that we
> would want all existing links to either the wiki or tickets etc to work
> without major changes. So I would think any access to
> https://issues.apache.org/bloodhound would resolve to the corresponding new
> page.
>
> Cheers
>
> John
> On 18 Feb 2015 12:19, "Gary Martin" <gj...@apache.org> 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 <br...@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/pmeantroduct 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
>>
>> It looks to me like a bit of work has been in progress. For some reason we
>> have a "Welcome to Trac 0.13dev" as our front page at the moment. Not so
>> great for us!
>>
>> Cheers,
>> Gary
>>
John,
OK, going through the basic options:
A) If we are living with /bloodhound as the baseurl without making
/bloodhound/main the global location, I think that this is the basic set
of stuff that probably requires redirecting:
/bloodhound/ticket(.*) -> /bloodhound/products/BLOODHOUND/ticket$1
/bloodhound/milestone(.*) -> /bloodhound/products/BLOODHOUND/milestone$1
/bloodhound/wiki/Bloodhound(.*) ->
/bloodhound/products/BLOODHOUND/wiki/Bloodhound$1
/bloodhound/wiki/Proposals(.*) ->
/bloodhound/products/BLOODHOUND/wiki/Proposals$1
/bloodhound/wiki/Ui(.*) -> /bloodhound/products/BLOODHOUND/wiki/Ui$1
With this scheme we should probably accept that
/bloodhound/wiki/WikiStart and all the equivalents should be left as the
global wiki front page. The same would go for the dashboard.
There are also timeline, roadmap, browser, report and query links that
we could consider but I could see us ignoring those. Perhaps queries
would be the most annoying links to lose of those.
B) Moving the baseurl at all should simplify things and should only
require one redirection rule. Moved down the path, a baseurl of
/bloodhound/main would only require something that avoided an infinite
redirection. So something like:
/bloodhound/(?!main)(.*) to /bloodhound/main/products/BLOODHOUND/%1
might be close to working. Anything other than /bloodhound in the base
would be a little simpler but not hugely; instead it would have the
apparent downside of disturbing INFRA.
Brane might have been pointing to another solution earlier. To be
honest, I don't mind too much what approach we take as long as the
implications are understood and the majority seem happy enough with the
choice.
Cheers,
Gary
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Ryan J Ollos <rj...@apache.org>.
On Wed, Feb 18, 2015 at 5:07 AM, John Chambers <ch...@apache.org> wrote:
> Hmm not sure what has happened to the start page. I will take a look later
> when I get home.
>
It looks like the trac-admin "wiki upgrade" command was executed on the
Bloodhound environment. There are about 50 pages that were upgraded with
the bloodhound whitelabeling redirects (a post-0.4 feature). For example:
https://issues.apache.org/bloodhound/wiki/TracWorkflow?action=history
Two strange things:
* Both entries in the history show version = 1:
https://issues.apache.org/bloodhound/wiki/TracWorkflow?action=history
* The history of the WikiStart page appears to exist, but when I tried to
delete version = 44, and then version = 43, it still shows the same content:
https://issues.apache.org/bloodhound/wiki/WikiStart?action=history
It's possible that we'll need to restore the database from a backup.
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
Hmm not sure what has happened to the start page. I will take a look later
when I get home.
I am still a little unclear on the redirects we need. I assumed that we
would want all existing links to either the wiki or tickets etc to work
without major changes. So I would think any access to
https://issues.apache.org/bloodhound would resolve to the corresponding new
page.
Cheers
John
On 18 Feb 2015 12:19, "Gary Martin" <gj...@apache.org> 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 <br...@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
>
> It looks to me like a bit of work has been in progress. For some reason we
> have a "Welcome to Trac 0.13dev" as our front page at the moment. Not so
> great for us!
>
> Cheers,
> Gary
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Branko Čibej <br...@wandisco.com>.
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 <br...@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
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Gary Martin <gj...@apache.org>.
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 <br...@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
It looks to me like a bit of work has been in progress. For some reason
we have a "Welcome to Trac 0.13dev" as our front page at the moment. Not
so great for us!
Cheers,
Gary
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
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 <br...@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
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Branko Čibej <br...@wandisco.com>.
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
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Gary Martin <gj...@apache.org>.
On 17/02/15 14:28, John Chambers wrote:
> Ok I think we have a plan. Now I just need to figure out how to implement
> it ;)
>
> The only thing is I think I am going to have to involve INFRA because I
> think the only way into our VM is via https://issues.apache.org/bloodhound
> and I don't think making any config changes to the Apache2 config on the vm
> will allow external access via another url i.e
> https://issues.apache.org/bhound.
>
> I am going to try and test this by installing a new instance of bloodhound
> 0.8.0 on the VM and try and access it via the above url. If this is not
> possible I will raise this with INFRA. They may also be the ones who can
> setup the redirect from https://issues.apache.org/bloodhound to
> https://issues.apache.org/bhound/product/BLOODHOUND
>
> I will keep you informed.
>
> Cheers
>
> John
Yes, it is probably wise to talk with INFRA about this to figure out
what they need to do. With our assumption that they will eventually take
control of the running, they might wish to assert their preference
instead. I don't think we need to be overly attached to a particular path.
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
So, has anyone got any problems with this part of the plan? Is there
anything that anyone thinks will come back to haunt us?
Cheers,
Gary
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
Ok I think we have a plan. Now I just need to figure out how to implement
it ;)
The only thing is I think I am going to have to involve INFRA because I
think the only way into our VM is via https://issues.apache.org/bloodhound
and I don't think making any config changes to the Apache2 config on the vm
will allow external access via another url i.e
https://issues.apache.org/bhound.
I am going to try and test this by installing a new instance of bloodhound
0.8.0 on the VM and try and access it via the above url. If this is not
possible I will raise this with INFRA. They may also be the ones who can
setup the redirect from https://issues.apache.org/bloodhound to
https://issues.apache.org/bhound/product/BLOODHOUND
I will keep you informed.
Cheers
John
On 17 February 2015 at 01:15, Gary Martin <ga...@wandisco.com> wrote:
> On 17 February 2015 at 00:18, Olemis Lang <ol...@gmail.com> wrote:
>
> > On 2/16/15, Ryan J Ollos <rj...@apache.org> wrote:
> > > On Mon, Feb 16, 2015 at 10:55 AM, John Chambers <ch...@apache.org>
> > wrote:
> > >
> > >> Brane,
> > >>
> > >> I do like this idea. The way I would see it setup would be that the
> only
> > >> things in the global environment / base url would be the bloodhound /
> > >> trac
> > >> wiki pages
> >
> > (IMHO) Important resources belonging in global environment :
> >
> > 1. Repository(ies)
> > 2. Wiki pages with guidelines explaining
> > * default BH user guide pages
> > (i.e. exclude WikiStart , BloodhoundInstall , ...)
> > * how to use this i.a.o/bh instance
> > * it's relation with other ASF services
> > * procedures like *how to setup new BH products*
> > * everything about this particular BH instance ...
> > 3. A completely new WikiStart
> > 4. Global admin panels
> > - What to do with plugin install form ?
> >
> > >> and potentially only tickets about the infrastructure of this
> > >> instance of bloodhound (though these could be in a new product as
> well).
> > >>
> >
> > should be a separate product , let's say INFRA , BH-SITE ... add your
> own
> > ;)
> >
> > >> We could then have a BH_ISSUES product which would contain all the old
> > >> tickets and attachments.
> > >>
> > >
> > > Extrapolating on what Brane said, it seems like everything in the
> current
> > > Bloodhound instance should go in the BH product, including future
> tickets
> > > and wiki pages.
> >
> > +1
> >
> > > The WikiStart page in the global wiki could contain some
> > > new content,
> >
> > +1 ... IMO it should be something like https://issues.apache.org/ and
> > may be improved with time . Alternately it may look like a dashboard ,
> > which is what seems to happen in https://issues.apache.org/jira , so
> > we could define the global default handler to be the DashboardModule .
> >
> > > and ultimately be a placeholder for future use when there are
> > > multiple projects hosted in Bloodhound and we need a global wiki to
> > orient
> > > users to all the projects, provide instruction on how to create new
> > > projects, etc ...
> > >
> >
> > There is a page for that i.e. /products in global environment .
> >
> > > Looking at the ASF Jira instance, the projects have URLs such as:
> > > https://issues.apache.org/jira/browse/FLUME
> > >
> > > So I think what we are talking about here is to have the new Bloodhound
> > > project be located at:
> > > https://issues.apache.org/bloodhound/bh (or
> > > https://issues.apache.org/bloodhound/project/bh)
> >
> > Considering BH default URL mapping this should be
> > https://issues.apache.org/bloodhound/products/bh
> >
> > > and have URLs with the base https://issues.apache.org/bloodhound
> > rewritten
> > > to https://issues.apache.org/bloodhound/bh
> > >
> >
> > HTTP 301 ? I'd rather prefer doing so . In fact
> > https://issues.apache.org/jira/ =>
> > https://issues.apache.org/jira/secure/Dashboard.jspa . Nevertheless
> > since there will be still a global env , which URLs should redirect
> > user and which ones should not ?
> >
> > > Having a separate project for Bloodhound infrastructure could be
> useful,
> > > e.g. BH_INFRA. There are probably a half dozen to a dozen open
> > > infrastructure-related tickets that could be copied to the new BH_INFRA
> > > instance.
> > >
> >
> > +1
> >
> > [...]
> >
> > --
> > Regards,
> >
> > Olemis - @olemis
> >
>
>
> I think we are getting close to the right approach here.
>
> Yes, it will be good to assume that infrastructure will eventually take
> over the global environment. The content until such time as they do take
> over could be limited to help pages. We may want to second guess some of
> what infra would like in that wiki but we shouldn't go too far without
> advice. A simple page listing of the other issue tracker resources and
> maybe the contained products might well be enough for the WikiStart.
>
> I am very happy with the idea of adding a second product alongside our own
> that we take on for the purpose of site maintenance. This may be a more
> appropriate place to document site setup. I would probably avoid naming it
> INFRA as I would like to avoid people mistaking it for the real infra site.
>
> Ryan pointing out the project keys from the apache jira instance reminded
> me that I currently think that long product prefixes may make a bit more
> sense in a public facing website. This should avoid inexplicable acronyms
> for baffling the uninitiated. This has to be contrasted with the extra
> hassle at typing longer names but I suspect it might be worth it.
>
> The leaves redirection and our base url. Unless we want to list all the
> pages we care to redirect (this may be hyperbole.. I may not have
> considered this enough) then it seems that we are destined for a change in
> the base url. It would be nice if we didn't have to reason through too many
> special cases. For the sake of an initial idea, I'm suggesting the
> following:
>
> https://issues.apache.org/bhound
> https://issues.apache.org/bhound/product/BLOODHOUND
> https://issues.apache.org/bhound/product/BHOUND-INFRA
>
> The permanent redirects can then for the most part be a simple replacement
> of the old base url for the new product:
>
> https://issues.apache.org/bloodhound =>
> https://issues.apache.org/bhound/product/BLOODHOUND
>
> There could be a few special cases that we may care about that are ignored
> of course.
>
> Cheers,
> Gary
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Gary Martin <ga...@wandisco.com>.
On 17 February 2015 at 00:18, Olemis Lang <ol...@gmail.com> wrote:
> On 2/16/15, Ryan J Ollos <rj...@apache.org> wrote:
> > On Mon, Feb 16, 2015 at 10:55 AM, John Chambers <ch...@apache.org>
> wrote:
> >
> >> Brane,
> >>
> >> I do like this idea. The way I would see it setup would be that the only
> >> things in the global environment / base url would be the bloodhound /
> >> trac
> >> wiki pages
>
> (IMHO) Important resources belonging in global environment :
>
> 1. Repository(ies)
> 2. Wiki pages with guidelines explaining
> * default BH user guide pages
> (i.e. exclude WikiStart , BloodhoundInstall , ...)
> * how to use this i.a.o/bh instance
> * it's relation with other ASF services
> * procedures like *how to setup new BH products*
> * everything about this particular BH instance ...
> 3. A completely new WikiStart
> 4. Global admin panels
> - What to do with plugin install form ?
>
> >> and potentially only tickets about the infrastructure of this
> >> instance of bloodhound (though these could be in a new product as well).
> >>
>
> should be a separate product , let's say INFRA , BH-SITE ... add your own
> ;)
>
> >> We could then have a BH_ISSUES product which would contain all the old
> >> tickets and attachments.
> >>
> >
> > Extrapolating on what Brane said, it seems like everything in the current
> > Bloodhound instance should go in the BH product, including future tickets
> > and wiki pages.
>
> +1
>
> > The WikiStart page in the global wiki could contain some
> > new content,
>
> +1 ... IMO it should be something like https://issues.apache.org/ and
> may be improved with time . Alternately it may look like a dashboard ,
> which is what seems to happen in https://issues.apache.org/jira , so
> we could define the global default handler to be the DashboardModule .
>
> > and ultimately be a placeholder for future use when there are
> > multiple projects hosted in Bloodhound and we need a global wiki to
> orient
> > users to all the projects, provide instruction on how to create new
> > projects, etc ...
> >
>
> There is a page for that i.e. /products in global environment .
>
> > Looking at the ASF Jira instance, the projects have URLs such as:
> > https://issues.apache.org/jira/browse/FLUME
> >
> > So I think what we are talking about here is to have the new Bloodhound
> > project be located at:
> > https://issues.apache.org/bloodhound/bh (or
> > https://issues.apache.org/bloodhound/project/bh)
>
> Considering BH default URL mapping this should be
> https://issues.apache.org/bloodhound/products/bh
>
> > and have URLs with the base https://issues.apache.org/bloodhound
> rewritten
> > to https://issues.apache.org/bloodhound/bh
> >
>
> HTTP 301 ? I'd rather prefer doing so . In fact
> https://issues.apache.org/jira/ =>
> https://issues.apache.org/jira/secure/Dashboard.jspa . Nevertheless
> since there will be still a global env , which URLs should redirect
> user and which ones should not ?
>
> > Having a separate project for Bloodhound infrastructure could be useful,
> > e.g. BH_INFRA. There are probably a half dozen to a dozen open
> > infrastructure-related tickets that could be copied to the new BH_INFRA
> > instance.
> >
>
> +1
>
> [...]
>
> --
> Regards,
>
> Olemis - @olemis
>
I think we are getting close to the right approach here.
Yes, it will be good to assume that infrastructure will eventually take
over the global environment. The content until such time as they do take
over could be limited to help pages. We may want to second guess some of
what infra would like in that wiki but we shouldn't go too far without
advice. A simple page listing of the other issue tracker resources and
maybe the contained products might well be enough for the WikiStart.
I am very happy with the idea of adding a second product alongside our own
that we take on for the purpose of site maintenance. This may be a more
appropriate place to document site setup. I would probably avoid naming it
INFRA as I would like to avoid people mistaking it for the real infra site.
Ryan pointing out the project keys from the apache jira instance reminded
me that I currently think that long product prefixes may make a bit more
sense in a public facing website. This should avoid inexplicable acronyms
for baffling the uninitiated. This has to be contrasted with the extra
hassle at typing longer names but I suspect it might be worth it.
The leaves redirection and our base url. Unless we want to list all the
pages we care to redirect (this may be hyperbole.. I may not have
considered this enough) then it seems that we are destined for a change in
the base url. It would be nice if we didn't have to reason through too many
special cases. For the sake of an initial idea, I'm suggesting the
following:
https://issues.apache.org/bhound
https://issues.apache.org/bhound/product/BLOODHOUND
https://issues.apache.org/bhound/product/BHOUND-INFRA
The permanent redirects can then for the most part be a simple replacement
of the old base url for the new product:
https://issues.apache.org/bloodhound =>
https://issues.apache.org/bhound/product/BLOODHOUND
There could be a few special cases that we may care about that are ignored
of course.
Cheers,
Gary
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Olemis Lang <ol...@gmail.com>.
On 2/16/15, Ryan J Ollos <rj...@apache.org> wrote:
> On Mon, Feb 16, 2015 at 10:55 AM, John Chambers <ch...@apache.org> wrote:
>
>> Brane,
>>
>> I do like this idea. The way I would see it setup would be that the only
>> things in the global environment / base url would be the bloodhound /
>> trac
>> wiki pages
(IMHO) Important resources belonging in global environment :
1. Repository(ies)
2. Wiki pages with guidelines explaining
* default BH user guide pages
(i.e. exclude WikiStart , BloodhoundInstall , ...)
* how to use this i.a.o/bh instance
* it's relation with other ASF services
* procedures like *how to setup new BH products*
* everything about this particular BH instance ...
3. A completely new WikiStart
4. Global admin panels
- What to do with plugin install form ?
>> and potentially only tickets about the infrastructure of this
>> instance of bloodhound (though these could be in a new product as well).
>>
should be a separate product , let's say INFRA , BH-SITE ... add your own ;)
>> We could then have a BH_ISSUES product which would contain all the old
>> tickets and attachments.
>>
>
> Extrapolating on what Brane said, it seems like everything in the current
> Bloodhound instance should go in the BH product, including future tickets
> and wiki pages.
+1
> The WikiStart page in the global wiki could contain some
> new content,
+1 ... IMO it should be something like https://issues.apache.org/ and
may be improved with time . Alternately it may look like a dashboard ,
which is what seems to happen in https://issues.apache.org/jira , so
we could define the global default handler to be the DashboardModule .
> and ultimately be a placeholder for future use when there are
> multiple projects hosted in Bloodhound and we need a global wiki to orient
> users to all the projects, provide instruction on how to create new
> projects, etc ...
>
There is a page for that i.e. /products in global environment .
> Looking at the ASF Jira instance, the projects have URLs such as:
> https://issues.apache.org/jira/browse/FLUME
>
> So I think what we are talking about here is to have the new Bloodhound
> project be located at:
> https://issues.apache.org/bloodhound/bh (or
> https://issues.apache.org/bloodhound/project/bh)
Considering BH default URL mapping this should be
https://issues.apache.org/bloodhound/products/bh
> and have URLs with the base https://issues.apache.org/bloodhound rewritten
> to https://issues.apache.org/bloodhound/bh
>
HTTP 301 ? I'd rather prefer doing so . In fact
https://issues.apache.org/jira/ =>
https://issues.apache.org/jira/secure/Dashboard.jspa . Nevertheless
since there will be still a global env , which URLs should redirect
user and which ones should not ?
> Having a separate project for Bloodhound infrastructure could be useful,
> e.g. BH_INFRA. There are probably a half dozen to a dozen open
> infrastructure-related tickets that could be copied to the new BH_INFRA
> instance.
>
+1
[...]
--
Regards,
Olemis - @olemislc
Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Branko Čibej <br...@wandisco.com>.
On 16.02.2015 22:50, Ryan J Ollos wrote:
> On Mon, Feb 16, 2015 at 10:55 AM, John Chambers <ch...@apache.org> wrote:
>
>> But like I said previously I am not an expert in Trac/Bloodhound or Apache
>> HTTP. So any help or pointers to documentation would be very gratefully
>> received.
>>
> I'm no expert either, so there could be significant oversights in the"plan"
> I've described.
If/when you need help with Apache configs, please ping me; I think I
have enough experience with redirect/rewrite magic to help. If the
problem is multiprodict configuration, I sure can ping one of the
authors of that to lend a hand.
-- Brane
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Ryan J Ollos <rj...@apache.org>.
On Mon, Feb 16, 2015 at 10:55 AM, John Chambers <ch...@apache.org> wrote:
> Brane,
>
> I do like this idea. The way I would see it setup would be that the only
> things in the global environment / base url would be the bloodhound / trac
> wiki pages and potentially only tickets about the infrastructure of this
> instance of bloodhound (though these could be in a new product as well).
>
> We could then have a BH_ISSUES product which would contain all the old
> tickets and attachments.
>
Extrapolating on what Brane said, it seems like everything in the current
Bloodhound instance should go in the BH product, including future tickets
and wiki pages. The WikiStart page in the global wiki could contain some
new content, and ultimately be a placeholder for future use when there are
multiple projects hosted in Bloodhound and we need a global wiki to orient
users to all the projects, provide instruction on how to create new
projects, etc ...
Looking at the ASF Jira instance, the projects have URLs such as:
https://issues.apache.org/jira/browse/FLUME
So I think what we are talking about here is to have the new Bloodhound
project be located at:
https://issues.apache.org/bloodhound/bh (or
https://issues.apache.org/bloodhound/project/bh)
and have URLs with the base https://issues.apache.org/bloodhound rewritten
to https://issues.apache.org/bloodhound/bh
Having a separate project for Bloodhound infrastructure could be useful,
e.g. BH_INFRA. There are probably a half dozen to a dozen open
infrastructure-related tickets that could be copied to the new BH_INFRA
instance.
> But like I said previously I am not an expert in Trac/Bloodhound or Apache
> HTTP. So any help or pointers to documentation would be very gratefully
> received.
>
I'm no expert either, so there could be significant oversights in the"plan"
I've described.
- Ryan
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
Brane,
I do like this idea. The way I would see it setup would be that the only
things in the global environment / base url would be the bloodhound / trac
wiki pages and potentially only tickets about the infrastructure of this
instance of bloodhound (though these could be in a new product as well).
We could then have a BH_ISSUES product which would contain all the old
tickets and attachments.
But like I said previously I am not an expert in Trac/Bloodhound or Apache
HTTP. So any help or pointers to documentation would be very gratefully
received.
Cheers
John
On 16 February 2015 at 16:37, Branko Čibej <br...@wandisco.com> wrote:
> On 16.02.2015 16:25, Olemis Lang wrote:
> > Hi John !
> > :)
> >
> > On 2/16/15, John Chambers <ch...@apache.org> wrote:
> >> I have spent more time on this over the weekend and I now have a copy of
> >> the live site on my local VM.
> > [...]
> >
> > \o/
> >
> >> I already had bloodhound v0.8
> >> installed so it was just a case of replacing the
> >> bloodhound/environments/main with the archived one and restoring the
> >> database. I had to make changes to the base and trac ini files because
> of
> >> path changes and I then had to do a trac-admin upgrade to get the
> database
> >> to the required version.
> >>
> > Database upgrade should not be quite problematic considering that
> > multi-product plugin's columns have not changed since some time and
> > 4.0 includes MP DB structure but not the other aspects , mainly the
> > isolated product envionments developed for BH>=0.6 . Something worth
> > considering is the state of other plugins e.g. relations . Is it
> > enabled and working ?
> >
> >> Now the main problem I have is that the process has created a new @
> >> prefixed default product under which all the old tickets and wiki pages
> can
> >> be found.
> > Would you mind if default product prefix is set to something different
> > , let's say BH ?
> >
> >> However I do not have a WikiStart page defined.
> > I guess you mean in the global environment i.e. at base URL .
> >
> >> So my question is
> >> what should I do?
> > It is possible to create the wiki page and that's it but ...
> >
> >> Bare in mind that I will most likely be doing something
> >> similar with the live i.a.o Bloodhound instance at some point.
> >>
> > ... the question is what's going to happen with all the URLs (e.g. in
> > messages instructions , archive , ...) pointing at i.a.o/bh/... now
> > available at i.a.o/products/PREFIX/... (PREFIX=@ or PREFIX=BH or ...)
> >
> >> The options I can think of are:
> >>
> >> 1. Change the setup so that we are using the default product to serve
> all
> >> the pages.
> >> 2. Create a new StartWiki page to allow the users to select the product
> >> they want to work with.
> >>
> > Considering the answers to questions above I might have another
> > proposal ... which is basically to continue hosting the default
> > product at i.a.o/bh other potential new products at
> > i.a.o/bh/products/PREFIX and global admin at some other
> > non-conflicting URL e.g. i.a.o/bh/global (<= but may a different
> > naming convention be chosen as well)
>
>
> I'd really hate having BH tickets etc. in the default product. They
> should be in the BH/bloodhound product. To maintain URL compatibility,
> we can design rewrite rules for the Apache config that make all
> product-scoped tickets, pages, etc. visible at their old locations.
>
> The reason why it makes sense to scope all BH stuff into its own product
> is that it will then be easier for other projects to adopt BH as their
> issue tracker. Most ASF projects currently use Jira, but some use
> Bugzilla and at least one uses the tracker at tigris.org. If we make
> transition to Bloodhound moderately easy, they may switch (and we may
> convince Infra to provide a more powerful VM for the BH host).
>
> -- Brane
>
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Branko Čibej <br...@wandisco.com>.
On 16.02.2015 16:25, Olemis Lang wrote:
> Hi John !
> :)
>
> On 2/16/15, John Chambers <ch...@apache.org> wrote:
>> I have spent more time on this over the weekend and I now have a copy of
>> the live site on my local VM.
> [...]
>
> \o/
>
>> I already had bloodhound v0.8
>> installed so it was just a case of replacing the
>> bloodhound/environments/main with the archived one and restoring the
>> database. I had to make changes to the base and trac ini files because of
>> path changes and I then had to do a trac-admin upgrade to get the database
>> to the required version.
>>
> Database upgrade should not be quite problematic considering that
> multi-product plugin's columns have not changed since some time and
> 4.0 includes MP DB structure but not the other aspects , mainly the
> isolated product envionments developed for BH>=0.6 . Something worth
> considering is the state of other plugins e.g. relations . Is it
> enabled and working ?
>
>> Now the main problem I have is that the process has created a new @
>> prefixed default product under which all the old tickets and wiki pages can
>> be found.
> Would you mind if default product prefix is set to something different
> , let's say BH ?
>
>> However I do not have a WikiStart page defined.
> I guess you mean in the global environment i.e. at base URL .
>
>> So my question is
>> what should I do?
> It is possible to create the wiki page and that's it but ...
>
>> Bare in mind that I will most likely be doing something
>> similar with the live i.a.o Bloodhound instance at some point.
>>
> ... the question is what's going to happen with all the URLs (e.g. in
> messages instructions , archive , ...) pointing at i.a.o/bh/... now
> available at i.a.o/products/PREFIX/... (PREFIX=@ or PREFIX=BH or ...)
>
>> The options I can think of are:
>>
>> 1. Change the setup so that we are using the default product to serve all
>> the pages.
>> 2. Create a new StartWiki page to allow the users to select the product
>> they want to work with.
>>
> Considering the answers to questions above I might have another
> proposal ... which is basically to continue hosting the default
> product at i.a.o/bh other potential new products at
> i.a.o/bh/products/PREFIX and global admin at some other
> non-conflicting URL e.g. i.a.o/bh/global (<= but may a different
> naming convention be chosen as well)
I'd really hate having BH tickets etc. in the default product. They
should be in the BH/bloodhound product. To maintain URL compatibility,
we can design rewrite rules for the Apache config that make all
product-scoped tickets, pages, etc. visible at their old locations.
The reason why it makes sense to scope all BH stuff into its own product
is that it will then be easier for other projects to adopt BH as their
issue tracker. Most ASF projects currently use Jira, but some use
Bugzilla and at least one uses the tracker at tigris.org. If we make
transition to Bloodhound moderately easy, they may switch (and we may
convince Infra to provide a more powerful VM for the BH host).
-- Brane
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
On 16 February 2015 at 15:25, Olemis Lang <ol...@gmail.com> wrote:
> Hi John !
> :)
>
> On 2/16/15, John Chambers <ch...@apache.org> wrote:
> > I have spent more time on this over the weekend and I now have a copy of
> > the live site on my local VM.
> [...]
>
> \o/
>
> > I already had bloodhound v0.8
> > installed so it was just a case of replacing the
> > bloodhound/environments/main with the archived one and restoring the
> > database. I had to make changes to the base and trac ini files because of
> > path changes and I then had to do a trac-admin upgrade to get the
> database
> > to the required version.
> >
>
> Database upgrade should not be quite problematic considering that
> multi-product plugin's columns have not changed since some time and
> 4.0 includes MP DB structure but not the other aspects , mainly the
> isolated product envionments developed for BH>=0.6 . Something worth
> considering is the state of other plugins e.g. relations . Is it
> enabled and working ?
>
How would I check this?
>
> > Now the main problem I have is that the process has created a new @
> > prefixed default product under which all the old tickets and wiki pages
> can
> > be found.
>
> Would you mind if default product prefix is set to something different
> , let's say BH ?
>
I didn't seem to get a choice here unless I can specify this prior to the
database upgrade.
>
> > However I do not have a WikiStart page defined.
>
> I guess you mean in the global environment i.e. at base URL .
>
> > So my question is
> > what should I do?
>
> It is possible to create the wiki page and that's it but ...
>
> > Bare in mind that I will most likely be doing something
> > similar with the live i.a.o Bloodhound instance at some point.
> >
>
> ... the question is what's going to happen with all the URLs (e.g. in
> messages instructions , archive , ...) pointing at i.a.o/bh/... now
> available at i.a.o/products/PREFIX/... (PREFIX=@ or PREFIX=BH or ...)
>
> > The options I can think of are:
> >
> > 1. Change the setup so that we are using the default product to serve all
> > the pages.
> > 2. Create a new StartWiki page to allow the users to select the product
> > they want to work with.
> >
>
> Considering the answers to questions above I might have another
> proposal ... which is basically to continue hosting the default
> product at i.a.o/bh other potential new products at
> i.a.o/bh/products/PREFIX and global admin at some other
> non-conflicting URL e.g. i.a.o/bh/global (<= but may a different
> naming convention be chosen as well)
>
> I think we might be limited here because Apache is the host and we might
not be able to specify other url's apart from i.a.o/bloodhound.
If you can give me some pointers on how I can do the migration and only
expose the existing tickets as product @ via the bloodhound url, that
should give me a good start.
> > I am no expert of administrating either Trac or Bloodhound, so any
> > suggestions would be welcome.
> >
>
> Thanks for your help and the time dedicated to make this happen .
>
> [...]
>
About time I start to contribute to the project.
>
> --
> Regards,
>
> Olemis - @olemislc
>
> Apache(tm) Bloodhound contributor
> http://issues.apache.org/bloodhound
> http://blood-hound.net
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Cheers
John
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Olemis Lang <ol...@gmail.com>.
Hi John !
:)
On 2/16/15, John Chambers <ch...@apache.org> wrote:
> I have spent more time on this over the weekend and I now have a copy of
> the live site on my local VM.
[...]
\o/
> I already had bloodhound v0.8
> installed so it was just a case of replacing the
> bloodhound/environments/main with the archived one and restoring the
> database. I had to make changes to the base and trac ini files because of
> path changes and I then had to do a trac-admin upgrade to get the database
> to the required version.
>
Database upgrade should not be quite problematic considering that
multi-product plugin's columns have not changed since some time and
4.0 includes MP DB structure but not the other aspects , mainly the
isolated product envionments developed for BH>=0.6 . Something worth
considering is the state of other plugins e.g. relations . Is it
enabled and working ?
> Now the main problem I have is that the process has created a new @
> prefixed default product under which all the old tickets and wiki pages can
> be found.
Would you mind if default product prefix is set to something different
, let's say BH ?
> However I do not have a WikiStart page defined.
I guess you mean in the global environment i.e. at base URL .
> So my question is
> what should I do?
It is possible to create the wiki page and that's it but ...
> Bare in mind that I will most likely be doing something
> similar with the live i.a.o Bloodhound instance at some point.
>
... the question is what's going to happen with all the URLs (e.g. in
messages instructions , archive , ...) pointing at i.a.o/bh/... now
available at i.a.o/products/PREFIX/... (PREFIX=@ or PREFIX=BH or ...)
> The options I can think of are:
>
> 1. Change the setup so that we are using the default product to serve all
> the pages.
> 2. Create a new StartWiki page to allow the users to select the product
> they want to work with.
>
Considering the answers to questions above I might have another
proposal ... which is basically to continue hosting the default
product at i.a.o/bh other potential new products at
i.a.o/bh/products/PREFIX and global admin at some other
non-conflicting URL e.g. i.a.o/bh/global (<= but may a different
naming convention be chosen as well)
> I am no expert of administrating either Trac or Bloodhound, so any
> suggestions would be welcome.
>
Thanks for your help and the time dedicated to make this happen .
[...]
--
Regards,
Olemis - @olemislc
Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
I have spent more time on this over the weekend and I now have a copy of
the live site on my local VM. The migration was fairly straight forward. I
used trac-admin hotcopy to create an archive including the postgres
database and copied that to my local VM. I already had bloodhound v0.8
installed so it was just a case of replacing the
bloodhound/environments/main with the archived one and restoring the
database. I had to make changes to the base and trac ini files because of
path changes and I then had to do a trac-admin upgrade to get the database
to the required version.
Now the main problem I have is that the process has created a new @
prefixed default product under which all the old tickets and wiki pages can
be found. However I do not have a WikiStart page defined. So my question is
what should I do? Bare in mind that I will most likely be doing something
similar with the live i.a.o Bloodhound instance at some point.
The options I can think of are:
1. Change the setup so that we are using the default product to serve all
the pages.
2. Create a new StartWiki page to allow the users to select the product
they want to work with.
I am no expert of administrating either Trac or Bloodhound, so any
suggestions would be welcome.
On 27 January 2015 at 07:59, John Chambers <ch...@apache.org> wrote:
> That would be good if you have time Ryan. I am in the process of creating
> my own local Ubuntu VM with version 0.4 installed so that I can test out
> the upgrade steps myself.
>
> Cheers
> John
> On 27 Jan 2015 07:52, "Ryan J Ollos" <rj...@apache.org> wrote:
>
>> On Mon, Jan 26, 2015 at 3:35 PM, Branko Čibej <br...@wandisco.com> wrote:
>>
>> > On 26.01.2015 22:03, John Chambers wrote:
>> > > As some of you may know I have recently taken an interest in the
>> > > infrastructure side of the project.
>> > > The following have be highlighted to me as the main priorities at the
>> > > moment:
>> > >
>> > > 1. Ensuring the demo servers are online.
>> > > 2. Re-enabling source browsing
>> > > 3. Upgrading i.a.o to version 0.8 from 0.4
>> > > 4. Dealing with spam tickets.
>> > > 5. Dealing with robot users.
>> > > 6. Setup multi product on i.a.o.
>> > >
>> > > I know there will be issues migrating tickets from a single to multi
>> > > product setup so I am proposing to create a new installation of
>> > bloodhound
>> > > at version 0.8 that will have multiple products defined. Migrating the
>> > wiki
>> > > content but leave the majority of the tickets in the old instance.
>> Which
>> > > will still be available for reference.
>> > >
>> > > We can then start afresh in a multi product setup. The new instance
>> will
>> > > have all the relevant plugins to prevent spam / robot users etc. And
>> will
>> > > be easier to maintain and upgrade.
>> > >
>> > > Let me know what you think.
>> >
>> > Sounds like a plan. FWIW, it really shouldn't be too hard to migrate the
>> > issues from an old, non-multi-product database to the new, multi-product
>> > setup, while maintaining product-specific issue numbers.
>> >
>>
>> Yeah, it would be more ideal if we could migrate over the issues as well.
>> I
>> don't think we have the exact steps documented anywhere, and perhaps it's
>> so trivial that the steps don't need to be documented, but I'm not
>> counting
>> on it. I could spend some time this weekend testing locally with a copy of
>> the database. Whichever way we go with i.a.o, it would be good for us to
>> understand the steps required to migrate older installations to
>> multiproduct, and document if needed, so any time spent wouldn't be
>> wasted.
>>
>>
>> > We can still get the old issue URLs to work by adding some smart rewrite
>> > rules to the HTTPd configuration.
>> >
>> > -- Brane
>> >
>> >
>>
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by John Chambers <ch...@apache.org>.
That would be good if you have time Ryan. I am in the process of creating
my own local Ubuntu VM with version 0.4 installed so that I can test out
the upgrade steps myself.
Cheers
John
On 27 Jan 2015 07:52, "Ryan J Ollos" <rj...@apache.org> wrote:
> On Mon, Jan 26, 2015 at 3:35 PM, Branko Čibej <br...@wandisco.com> wrote:
>
> > On 26.01.2015 22:03, John Chambers wrote:
> > > As some of you may know I have recently taken an interest in the
> > > infrastructure side of the project.
> > > The following have be highlighted to me as the main priorities at the
> > > moment:
> > >
> > > 1. Ensuring the demo servers are online.
> > > 2. Re-enabling source browsing
> > > 3. Upgrading i.a.o to version 0.8 from 0.4
> > > 4. Dealing with spam tickets.
> > > 5. Dealing with robot users.
> > > 6. Setup multi product on i.a.o.
> > >
> > > I know there will be issues migrating tickets from a single to multi
> > > product setup so I am proposing to create a new installation of
> > bloodhound
> > > at version 0.8 that will have multiple products defined. Migrating the
> > wiki
> > > content but leave the majority of the tickets in the old instance.
> Which
> > > will still be available for reference.
> > >
> > > We can then start afresh in a multi product setup. The new instance
> will
> > > have all the relevant plugins to prevent spam / robot users etc. And
> will
> > > be easier to maintain and upgrade.
> > >
> > > Let me know what you think.
> >
> > Sounds like a plan. FWIW, it really shouldn't be too hard to migrate the
> > issues from an old, non-multi-product database to the new, multi-product
> > setup, while maintaining product-specific issue numbers.
> >
>
> Yeah, it would be more ideal if we could migrate over the issues as well. I
> don't think we have the exact steps documented anywhere, and perhaps it's
> so trivial that the steps don't need to be documented, but I'm not counting
> on it. I could spend some time this weekend testing locally with a copy of
> the database. Whichever way we go with i.a.o, it would be good for us to
> understand the steps required to migrate older installations to
> multiproduct, and document if needed, so any time spent wouldn't be wasted.
>
>
> > We can still get the old issue URLs to work by adding some smart rewrite
> > rules to the HTTPd configuration.
> >
> > -- Brane
> >
> >
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Ryan J Ollos <rj...@apache.org>.
On Mon, Jan 26, 2015 at 3:35 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 26.01.2015 22:03, John Chambers wrote:
> > As some of you may know I have recently taken an interest in the
> > infrastructure side of the project.
> > The following have be highlighted to me as the main priorities at the
> > moment:
> >
> > 1. Ensuring the demo servers are online.
> > 2. Re-enabling source browsing
> > 3. Upgrading i.a.o to version 0.8 from 0.4
> > 4. Dealing with spam tickets.
> > 5. Dealing with robot users.
> > 6. Setup multi product on i.a.o.
> >
> > I know there will be issues migrating tickets from a single to multi
> > product setup so I am proposing to create a new installation of
> bloodhound
> > at version 0.8 that will have multiple products defined. Migrating the
> wiki
> > content but leave the majority of the tickets in the old instance. Which
> > will still be available for reference.
> >
> > We can then start afresh in a multi product setup. The new instance will
> > have all the relevant plugins to prevent spam / robot users etc. And will
> > be easier to maintain and upgrade.
> >
> > Let me know what you think.
>
> Sounds like a plan. FWIW, it really shouldn't be too hard to migrate the
> issues from an old, non-multi-product database to the new, multi-product
> setup, while maintaining product-specific issue numbers.
>
Yeah, it would be more ideal if we could migrate over the issues as well. I
don't think we have the exact steps documented anywhere, and perhaps it's
so trivial that the steps don't need to be documented, but I'm not counting
on it. I could spend some time this weekend testing locally with a copy of
the database. Whichever way we go with i.a.o, it would be good for us to
understand the steps required to migrate older installations to
multiproduct, and document if needed, so any time spent wouldn't be wasted.
> We can still get the old issue URLs to work by adding some smart rewrite
> rules to the HTTPd configuration.
>
> -- Brane
>
>
Re: Dogfooding multi product on i.a.o/bloodhound
Posted by Branko Čibej <br...@wandisco.com>.
On 26.01.2015 22:03, John Chambers wrote:
> As some of you may know I have recently taken an interest in the
> infrastructure side of the project.
> The following have be highlighted to me as the main priorities at the
> moment:
>
> 1. Ensuring the demo servers are online.
> 2. Re-enabling source browsing
> 3. Upgrading i.a.o to version 0.8 from 0.4
> 4. Dealing with spam tickets.
> 5. Dealing with robot users.
> 6. Setup multi product on i.a.o.
>
> I know there will be issues migrating tickets from a single to multi
> product setup so I am proposing to create a new installation of bloodhound
> at version 0.8 that will have multiple products defined. Migrating the wiki
> content but leave the majority of the tickets in the old instance. Which
> will still be available for reference.
>
> We can then start afresh in a multi product setup. The new instance will
> have all the relevant plugins to prevent spam / robot users etc. And will
> be easier to maintain and upgrade.
>
> Let me know what you think.
Sounds like a plan. FWIW, it really shouldn't be too hard to migrate the
issues from an old, non-multi-product database to the new, multi-product
setup, while maintaining product-specific issue numbers.
We can still get the old issue URLs to work by adding some smart rewrite
rules to the HTTPd configuration.
-- Brane