Please do not use http://puppetagain.pub.build.mozilla.org for high-reliability Python installs

RESOLVED FIXED

Status

Release Engineering
General Automation
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: dustin, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [SPOF])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
This vhost is external, and single-hosted.  It's intended as an means to expose puppetagain' data to external users via rsync and http.  If it goes down, meh, external users can't see the data for a while.  No great emergency, no trees closed.

In PuppetAgain in general, resiliency is client-side, meaning that clients using data on puppet masters should be prepared to search for a working puppet master.  It's fine to use this host for stuff that can break for a few hours, but not for things that will close the tree.

On PuppetAgain-managed systems, ~/.pip/pip.conf is configured to point to all of the mirrors of this data on all of the puppetagain masters.  This is the correct way to install Python packages reliably.

For the duration of our not having everything managed by PuppetAgain, it'd be best to replicate this config some other way (old-puppet? mozharness?) and use it for the Python installs.

http://mxr.mozilla.org/build/search?string=puppetagain.pub.build.mozilla.org
suggests a bunch of places to fix this, but they all seem mozharness-related, so maybe that's not too bad.
Blocks: 843502
We now run unit tests officially through mozharness.

For instance, what should I run instead of this?
/builds/panda-0131/test/build/venv/bin/pip install --find-links http://puppetagain.pub.build.mozilla.org/data/python/packages mozpoolclient

Updated

4 years ago
Duplicate of this bug: 843502
(Reporter)

Comment 3

4 years ago
pip install mozpoolclient

should do the trick, assuming ~/.pip/pip.conf is in place.

http://hg.mozilla.org/build/puppet/file/63a5b3005adb/modules/python/templates/user-pip-conf.erb
Hrmm... we should look at deploying that to the Windows slaves and verify that the foopies, linux and mac machines have it deployed.

Comment 5

4 years ago
Bug 852473 comment 5 through 15 have some discussion about this bug.

Comment 6

4 years ago
Created attachment 727015 [details] [diff] [review]
puppetagain/data/ -> repos/
Assignee: nobody → aki
Attachment #727015 - Flags: review?(armenzg)
Attachment #727015 - Flags: review?(armenzg) → review+

Comment 7

4 years ago
Comment on attachment 727015 [details] [diff] [review]
puppetagain/data/ -> repos/

http://hg.mozilla.org/build/mozharness/rev/9d66f86b5b69

I'll push to Cedar and wait for some green before merging.
Attachment #727015 - Flags: checked-in+

Comment 8

4 years ago
Seeing green on Cedar.
Merged to production.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 9

4 years ago
This is better, but not resilient yet.

http://repos just points to the nearest puppet server, so it's no more fault-tolerant than pointing at that server itself, although it is a shorter path than puppetagain.pub.b.m.o.  

As I indicated in comment 3, the correct fix here is to use a pip.conf that lists multiple mirrors:
  http://hg.mozilla.org/build/puppet/file/tip/modules/python/templates/user-pip-conf.erb
and then pip install specific versions of packages (bug 851305).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 10

4 years ago
Ok.  I'm not working on comment 9.
Assignee: aki → nobody
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
(Reporter)

Comment 11

3 years ago
I think mozharness is consistently using pypi.pub/pvt.build.mozilla.org now, right?
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago3 years ago
Flags: needinfo?(aki)
Resolution: --- → FIXED

Comment 12

3 years ago
Afaict yes. http://mxr.mozilla.org/build/search?string=puppetagain&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=build
Flags: needinfo?(aki)
You need to log in before you can comment on or make changes to this bug.