Closed Bug 967642 (bzr-decom) Opened 9 years ago Closed 6 years ago

[tracker] Decommission


(Developer Services :: General, task)

Not set


(Not tracked)



(Reporter: fox2mike, Unassigned)



(Keywords: spring-cleaning, Whiteboard: [kanban:engops:] )

Once Bug 929685 is complete, and we have the blessings of mcote and team, let's kill
Assignee: server-ops → server-ops-webops
Group: infra
Component: Server Operations → WebOps: Source Control
Depends on: 929685
Product: → Infrastructure & Operations
QA Contact: shyam → nmaul
Keywords: spring-cleaning
Note that we should keep it up for a while after the migration, mainly because (for whatever reason) the suggested Bugzilla upgrade path has always been to pull from source.  I've posted instructions for moving an existing Bugzilla site from bzr to git, but it is unreasonable to expect admins to do this to get, say, a small security fix released shortly after migration.

LpSolit, one of the most active upstream contributors, thinks we should keep bzr up until all currently supported releases (4.0, 4.2, 4.4) are EOLed.  That, however, is very far away given the cadence of major Bugzilla releases these days.  Regardless, I would say that the minimum should be 6 months.
(In reply to Mark Côté ( :mcote ) from comment #1)
> Note that we should keep it up for a while after the migration, mainly
> because (for whatever reason) the suggested Bugzilla upgrade path has always
> been to pull from source.

The reason is that it's much easier to upgrade via bzr, which will merge changes into your existing installation directly than to download the tarball, uncompress it, copy your customizations into it, copy configuration files, and replace the old directory by the new one.
Depends on: 968636
Duplicate of this bug: 983209
Depends on: 973298
Summary: Decommission → [tracker] Decommission
Component: WebOps: Source Control → General
Product: Infrastructure & Operations → Developer Services
Whiteboard: [kanban:engops:]
Whiteboard: [kanban:engops:] → [kanban:engops:]
bzr crashed on my watch, 

[root@bzr2.dmz.scl3 ~]# tail /var/log/loggerhead/loggerheadd.log
    return prober.probe_transport(transport)
  File "/usr/lib64/python2.6/site-packages/bzrlib/", line 1250, in probe_transport
    format_string = transport.get_bytes(".bzr/branch-format")
  File "/usr/lib64/python2.6/site-packages/bzrlib/transport/", line 623, in get_bytes
    f = self.get(relpath)
  File "/usr/lib64/python2.6/site-packages/bzrlib/transport/", line 170, in get
    self._translate_error(e, path)
  File "/usr/lib64/python2.6/site-packages/bzrlib/transport/", line 352, in _translate_error
    raise errors.PermissionDenied(path, extra=e)
PermissionDenied: Permission denied: "/root/readonly+/var/www/html/": [Errno 13] Permission denied: u'/root/readonly+/var/www/html/'
"service loggerheadd restart" cleared it. nfc why it got out of whack, nothing should be changing on that server.
Not sure, I tried restarting multiple times and each time I would get the same error in comment #4.
Depends on: 1079449
Alias: bzr-decom
Depends on: 1155525
Depends on: 1155526
The git->bzr mirror on got shut down about an hour ago.  We've had it running in parallel on bzr.m.o and for the last week, and it's been doing fine and dandy in its new home, except for the fact that bzr uses a random number as part of the commit identifier, so the two repos are out-of-sync with each other, and show up as conflicting if you switch between them, even though the commit logs and content of the commits look identical.  By shutting off the mirror on and then doing one last rsync to, the commits they have in common will match, and users switching to will then pick up anything newer.

I just filed additional bugs with the last remaining steps to clean this up.  As soon as bug 1155526 is fixed, can go away.
No longer depends on: 1155525
No longer depends on: 1155526
bzr.b.o still needs a few tweaks, but I announced the switchover last week to dev.apps.bugzilla and the Bugzilla Update blog, so I don't think they needs to block this bug.
Depends on: 1155526
Assignee: server-ops-webops → nobody
QA Contact: nmaul
i think we can call this done
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.