Ben Kero [:bkero] Reporter
	Description • 12 years ago

Our version of hg is out of date, and should be updated.  The 2.0.x version has historically caused incompatibility issues with developers running 2.1.x (bug 725362)

A staging environment should be set up for releng to test against this new version.

I have already created a 2.1.2 RPM for this purpose.

	Corey Shields [:cshields]
	Comment 1 • 12 years ago

bumping this to 2.2.3

Also need to do this asap to pick up http://www.selenic.com/hg/rev/7bf48bc7de23

	Melissa O'Connor [:melissa]
	Comment 2 • 12 years ago

Any updates here?

	Ben Kero [:bkero] Reporter
	Comment 3 • 12 years ago

I can update this any time (and in fact have on our test node, hg1.dmz.scl3.mozilla.com).  I need releng to validate that it does not create any issues for them.  I asked in #build for someone from their team to assist me with this.

	Rain [:rain1] (inactive)
	Comment 4 • 12 years ago

After the upgrade, can we make try and try-comm-central non-publishing repositories? http://mercurial.selenic.com/wiki/Phases#What_is_a_.22publishing_repository.22.3F

	Hal Wine [:hwine] (use NI)
	Comment 5 • 12 years ago

Please verify access to hg1.dmz.scl3.mozilla.com from the build vpn (where we'll run our tests). ATM, the host name does not resolve, so I can't verify access on ports 80, 443, & 22:
 [hwine@github-sync1-dev.dmz.scl3 ~]$ hostname
 github-sync1-dev.dmz.scl3.mozilla.com
 [hwine@github-sync1-dev.dmz.scl3 ~]$ host hg1.dmz.scl3.mozilla.com
 Host hg1.dmz.scl3.mozilla.com not found: 3(NXDOMAIN)

Also, there was discussion about doing the deploy only to the webheads to help with the try performance issues. Can you clarify if the plan is to deploy everywhere, or just on the webheads?

	Ben Kero [:bkero] Reporter
	Comment 6 • 12 years ago

The hostname is hgweb1.dmz.scl3.mozilla.com, the hostname you have entered is 'hg1.dmz...'

	Ben Kero [:bkero] Reporter
	Comment 7 • 12 years ago

There were speedups in in several methods that try uses intensively.  We are not fragmenting the hg servers to try and other repositories, so this deployment will affect all hg-hosting servers.

Our current plan for try is to use local disks for caching improvement.  This is currently being tested on hgweb1.dmz.scl3, and is why it's already running hg 2.2.3.

	Hal Wine [:hwine] (use NI)
	Comment 8 • 12 years ago

(In reply to Ben Kero [:bkero] from comment #7)
> so this
> deployment will affect all hg-hosting servers.

Does "hg-hosting" include the commitable ssh accessed servers? If so, we need ssh access to the test machine as well, so we can check operations that activate hooks. (Thanks for correcting the host name.)

	Ben Kero [:bkero] Reporter
	Comment 9 • 12 years ago

We could deploy 2.2.3 on webheads first, then the ssh servers later, although I'd greatly prefer to simplify things by upgrading everything at once.

Our patched version of hg is no longer required.  I checked the hook running code in hooks.py in the mercurial source, and it is now performing the same sort() procedure that our patched version did (albeit in a different place).

I'll talk to people about getting you access to do your testing.

	Ben Kero [:bkero] Reporter
	Comment 10 • 12 years ago

2.3 is out now, let's test against that

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)
	Comment 11 • 12 years ago

(In reply to Ben Kero [:bkero] from comment #10)
> 2.3 is out now, let's test against that

Ben, Mercurial updates at the start of each month, so 2.3.1 is out w/ some hotfixes.

	Shyam Mani [:fox2mike] Assignee
	Comment 12 • 12 years ago

Pushing this to next quarter, Ben is busy working on git.m.o

	Ed Morley [:emorley]
	Comment 13 • 12 years ago

2.4 has some substantial speedups (likely primarily only for dev workflow, but still won't hurt to have on hg.m.o):
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.4.1_.282012-12-03.29

	Shyam Mani [:fox2mike] Assignee
	Comment 14 • 12 years ago

(In reply to Ed Morley [UTC+0; email:edmorley@moco] from comment #13)
> 2.4 has some substantial speedups (likely primarily only for dev workflow,
> but still won't hurt to have on hg.m.o):
> http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.4.1_.282012-12-03.29

Well, I'd like releng to approve 2.3 first and then we can jump on to 2.4?

	Ed Morley [:emorley]
	Comment 15 • 12 years ago

catlee, I thought this was blocked on IT, but it is actually waiting for releng approval. Is there someone that could look at this?

Cheers :-)

	Shyam Mani [:fox2mike] Assignee
	Comment 16 • 12 years ago

(In reply to Ed Morley [UTC+0; email:edmorley@moco] from comment #15)
> catlee, I thought this was blocked on IT, but it is actually waiting for
> releng approval. Is there someone that could look at this?
> 
> Cheers :-)

https://bugzilla.mozilla.org/show_bug.cgi?id=781012

	Ed Morley [:emorley]
	Comment 17 • 12 years ago

Ah missed that, thank you.

	Rain [:rain1] (inactive)
	Comment 18 • 12 years ago

Note that in general hg sometimes benefits performance-wise from having client version = server version. However I wouldn't let that hold you back from upgrading hg.

	Hal Wine [:hwine] (use NI)
	Comment 19 • 11 years ago

current staging and qualification efforts are on hg version 2.4.5 -- updating summary t

	Hal Wine [:hwine] (use NI)
	Comment 20 • 11 years ago

(In reply to Hal Wine [:hwine] from comment #19)
> current staging and qualification efforts are on hg version 2.4.5 --

Summary is correct - 2.5.4 is current target

	Shyam Mani [:fox2mike] Assignee
	Comment 21 • 11 years ago

Copy pasting from email sent out by Ben earlier :

The upgrade plan is as follows:
1. Add the updated package to Mozilla's package repository. This package has already been created and is operating on the staging host.
2. Remove one (out of 8) hosts serving http://hg.mozilla.org/ from the load balancer.
3. Perform the package upgrade.
4. Run tests against this web head to ensure that a selection of HTTP requests are served correctly (including hg clones).
5. Add the host back into the load balancer pool.
6. Repeat steps 2-5 for the remaining hosts.
7. Upgrade the package on the hot standby SSH host.
8. Confirm hg pushes work on the hot standby host.
9. Failover on the load balancer to the hot standby.
10. Repeat the package install on the other SSH host.

TL;DR: This plan means that under ideal conditions no outage will be experienced and risk has been minimized. A staging environment has been set up to simulate this upgrade process and ensure no incompatibilities exist with our code and the newer version.

Looking for a 2 hour window on June 1st for this upgrade. hg.mozilla.org will be completely offline for the duration of the upgrade.

	Gordon P. Hemsley [:GPHemsley]
	Comment 22 • 11 years ago

(In reply to Shyam Mani [:fox2mike] from comment #21)
> This plan means that under ideal conditions no outage will be
> experienced and risk has been minimized.
> 
> hg.mozilla.org
> will be completely offline for the duration of the upgrade.

Isn't this contradictory? Or am I misunderstanding something?

	Shyam Mani [:fox2mike] Assignee
	Comment 23 • 11 years ago

(In reply to Gordon P. Hemsley [:gphemsley] from comment #22)
> (In reply to Shyam Mani [:fox2mike] from comment #21)
> > This plan means that under ideal conditions no outage will be
> > experienced and risk has been minimized.
> > 
> > hg.mozilla.org
> > will be completely offline for the duration of the upgrade.
> 
> Isn't this contradictory? Or am I misunderstanding something?

You're not going to be able to commit to hg when we're upgrading the commit hosts (of which there are two). The tree will be closed for the duration of the upgrade. This doesn't stop you from checking out things, but we'd like to minimize probable issues by stopping check-in for a bit.

	Shyam Mani [:fox2mike] Assignee
	Comment 24 • 11 years ago

Approved by the CAB for June 1st. Time TBD.

	Hal Wine [:hwine] (use NI)
	Comment 25 • 11 years ago

draft steps with test points: https://etherpad.mozilla.org/GGi6ELTUCd

	Shyam Mani [:fox2mike] Assignee
	Comment 26 • 11 years ago

This is done. Woo! 

Trees will be re-opened after other accompanying work (see bug 878494) is complete.