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.
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
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.
Bug 852473 comment 5 through 15 have some discussion about this bug.
Created attachment 727015 [details] [diff] [review] puppetagain/data/ -> repos/
Assignee: nobody → aki
Attachment #727015 - Flags: review?(armenzg)
Attachment #727015 - Flags: review?(armenzg) → review+
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+
Seeing green on Cedar. Merged to production.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
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 → ---
Ok. I'm not working on comment 9.
Assignee: aki → nobody
Product: mozilla.org → Release Engineering
I think mozharness is consistently using pypi.pub/pvt.build.mozilla.org now, right?
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 5 years ago
Resolution: --- → FIXED
Afaict yes. http://mxr.mozilla.org/build/search?string=puppetagain&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=build
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.