|Questions on upgrading Gerrit.||Joshua J. Kugler||9/27/12 7:08 PM|
I have two questions.
"*WARNING:* Upgrading to 2.5.x requires the server be first upgraded to 2.1.7
(or a later 2.1.x version), and then to 2.5.x. If you are upgrading from
2.2.x.x or newer, you may ignore this warning and upgrade directly to 2.5.x."
So, I have 2.1.8 (which is later than 2.1.7), but then it says "If you are
upgrading from 2.2.x.x or newer..." What about releases between 2.1.7 and
2.2.x.x? Can I upgrade directly from 2.1.8 to 2.5?
2) Glitch (?) in upgrade
So, I downloaded gerrit-full-2.5-rc0.war, and ran it thusly:
java -jar gerrit-full-2.5-rc0.war init -d /path/to/existing/install
But, it instead of just walking through the upgrade, it 1) started presenting
me with questions about config, even though there is an existing config, and 2)
the defaults it offered me did not match with what was in the existing config
file. I can see presenting the current config as defaults to double-check the
config before upgrade, but the prompts not even matching the current config
seems a big odd. Is this designed behavior, or is it a bug?
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: peda...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
|Re: Questions on upgrading Gerrit.||Shawn Pearce||9/27/12 9:42 PM|
On Thu, Sep 27, 2012 at 7:08 PM, Joshua J. Kugler <jos...@azariah.com> wrote:Yes. What is missing is the ability to do 2.1.5 -> 2.2.x for example.
We deleted those ancient upgrade paths in 2.2.0.
This is normal. init runs in an interactive mode and prompts with the
If you pass --batch it won't prompt, it will just do the upgrade. At
the end you will be given a block of SQL you have to run by hand to
clean up the database. If you omit --batch (as you did above) you will
be shown this block of SQL and asked if you want Gerrit to run it
This does seem to be a problem. Can the user you ran the init command
as actually read the file at
/path/to/existing/install/etc/gerrit.config ? It seems like maybe not
if the prompts aren't describing current settings.
|Re: Questions on upgrading Gerrit.||Joshua J. Kugler||9/28/12 4:58 PM|
On Thursday, September 27, 2012 21:42:28 Shawn Pearce wrote:Thanks. It might be clearer if it said something along the lines of:
To upgrade to 2.5, gerrit must be at version 2.1.7 or later. If your Gerrit
version is older than 2.1.7, please upgrade to 2.1.7 first, then to 2.5.
> This does seem to be a problem. Can the user you ran the init commandI ran the following (as 'gerrit', the user as which gerrit runs):
$ ls -l /opt/local/gerrit/review.whamcloud.com/etc/gerrit.config
-rw-r--r-- 1 gerrit root 1362 Jun 7 17:14
java -jar gerrit-full-2.5-rc0.war init -d /opt/local/gerrit/review.domain.com
And I get this:
$ java -jar gerrit-full-2.5-rc0.war init -d
*** Gerrit Code Review 2.5-rc0
*** Git Repositories
Location of Git repositories [/srv/source/git]:
*** SQL Database
Database server type [H2/?]:
It gets the first one right (based on past preferences) but then doesn't
default to MySQL (the currently used DB).
If i do this:
$ java -jar gerrit-full-2.5-rc0.war init --batch -d
Upgrading database schema from version 52 to 53 ...
Exception in thread "main" com.google.gwtorm.server.OrmException: Cannot
create repository -- All Projects --
(I'll attach the full traceback)
So, as of right now, I'm stuck.
|Re: Questions on upgrading Gerrit.||Shawn Pearce||9/28/12 6:37 PM|
I wonder how you have the database configured. If its not the standard
way its written into gerrit.config, maybe the init code is confused
and doesn't know what to do.
"Creating directories for /srv/source/git/-- All Projects --.git failed"
Seems your user can't make this directory on your filesystem.
|Re: Questions on upgrading Gerrit.||Chris Barrera||10/1/12 7:49 AM|
We had this same problem going from 2.1.8->2.3 where All-Projects was attempted to be created twice, and removing it to restart the upgrade resulted in duplicate groups uuids in refs/meta/config... https://groups.google.com/forum/?fromgroups=#!searchin/repo-discuss/Barrera/repo-discuss/6pRno8Mwzhw/iRI1D42-hBwJ
|Re: Questions on upgrading Gerrit.||Joshua J. Kugler||10/1/12 4:19 PM|
On Friday, September 28, 2012 18:37:43 Shawn Pearce wrote:So, yes, /srv/source/git was owned by root (as we usually create repos under
directories owned by gerrit). But the question is: why is trying to create
repos at all? There are "permission only" projects. I see it's trying to
create projects named after teh "permissions projects." Is that expected?
Guess I'll need to read back through the change log.
But, on to the errors. :) So, I get this (full traceback attached). Is there
a way to get a more complete error message (see Caused by: at the end of the
traceback). I googled, and didn't get anything relevant.
Upgrading database schema from version 52 to 53 ...Upgrading database schema from version 53 to 54 ...
Upgrading database schema from version 54 to 55 ...
Renaming "-- All Projects --" to "All-Projects"
Upgrading database schema from version 55 to 56 ...
Upgrading database schema from version 56 to 57 ...
Upgrading database schema from version 57 to 58 ...
Upgrading database schema from version 58 to 59 ...
Upgrading database schema from version 59 to 60 ...
Exception in thread "main" com.google.gwtorm.server.OrmException: update
failure on change_messages
|Re: Questions on upgrading Gerrit.||Magnus Bäck||10/1/12 4:30 PM|
On Monday, October 01, 2012 at 19:19 EDT,
"Joshua J. Kugler" <jos...@azariah.com> wrote:
> So, yes, /srv/source/git was owned by root (as we usually create reposThis is expected. As of Gerrit 2.2, project settings were moved
to the refs/meta/config branch of each git. This means that also
permissions-only projects need a git.
|Re: Questions on upgrading Gerrit.||Shawn Pearce||10/1/12 5:47 PM|
On Mon, Oct 1, 2012 at 4:19 PM, Joshua J. Kugler <jos...@azariah.com> wrote:
...Looks like you have some disagreement between Gerrit and your database
about what character encoding should be used. Gerrit read something
from the database, then tried to store it back, and the database
doesn't like the encoding selected. This suggests a mismatch between
how the database is setup for character encoding, and maybe what the
JDBC driver Gerrit is using knows.
|Re: Questions on upgrading Gerrit.||Joshua J. Kugler||10/1/12 6:03 PM|
Ah, crud. OK. The server is set to default to utf8:
But there are some tables with a latin1 encoding. Well...I'll give converting
those a go, and see if my results change.
Thanks for all your help so far. :)
|Re: Questions on upgrading Gerrit.||Joshua J. Kugler||10/1/12 6:52 PM|
On Monday, October 01, 2012 17:03:36 Joshua J. Kugler wrote:So, I tried to convert t UTF8. But I hit this:
Well, I'm calling it a day. Will keep you updated on progress. :-D
I suppose I could convert all tables to latin1 and see if that fixes the issue,
but I really don't want to do that. Maybe I'll convert it to PostgreSQL. :P
|Re: Questions on upgrading Gerrit.||Shawn Pearce||10/1/12 7:20 PM|
On Mon, Oct 1, 2012 at 6:52 PM, Joshua J. Kugler <jos...@azariah.com> wrote:Does switching to InnoDB increase the maximum primary key length?
|Re: Questions on upgrading Gerrit.||Bailey, Darragh||10/2/12 2:51 AM|
On 02/10/12 02:52, Joshua J. Kugler wrote:No need to go that extreme :P
You might find the script attached to this launchpad bug useful
As an added bonus, switching to utf8 & innodb fixes the following
problem as well:
|Re: Questions on upgrading Gerrit.||Joshua J. Kugler||11/7/12 5:02 PM|
On Monday, October 01, 2012 19:20:13 Shawn Pearce wrote:Yes, it does.
I converted all tables to InnoDB, then ran this:
echo "ALTER TABLE $T CONVERT TO CHARACTER SET utf8;"|mysql reviewdb2;
for all tables, and received no errors.
Now, trying to run the gerit upgrade via:
sudo -u gerrit java -jar gerrit-full-2.5.war init --batch -d
I get the attached traceback, but the relevant parts are:
Caused by: java.sql.BatchUpdateException: Incorrect string value: '\xA0To
re...' for column 'message' at row 1
So, presumably, if that's what it pulls out of the database, it should be able
to put it back in the database, yes?
Does this indicate I simply have bad UTF data I will need to trace down
manually and fix?