Closed
Bug 597913
Opened 15 years ago
Closed 14 years ago
stop mounting NFS on slaves/masters
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: bhearsum)
References
Details
Attachments
(1 file)
34.26 KB,
patch
|
rail
:
review+
bhearsum
:
checked-in+
|
Details | Diff | Splinter Review |
We mounted NFS For serving puppet files for quite awhile. At this time, I don't think we serve anything on it anymore, and we should stop mounting it.
We still use it to share files between production-puppet/staging-puppet, so I'm not sure what to do there.
Comment 1•15 years ago
|
||
Possible dup of bug 597912.
I'm asked for this several times - this method just won't scale. You can't expect hundreds of hosts to reliably connect to a remote NFS host. IT doesn't use NFS for file distribution.
Comment 2•15 years ago
|
||
Is bug 597912 intentionally closed ?
Comment 3•15 years ago
|
||
No. I cleared the flags on it.
Assignee | ||
Comment 4•15 years ago
|
||
I'll be doing this, still don't have an ETA.
Assignee: nobody → bhearsum
Assignee | ||
Comment 5•15 years ago
|
||
This should remove all of our mounting of NFS. As far as I can tell, the only place that still mounts it is 32-bit linux build machines, as I did some removal of NFS in bug 552058. So, this patch:
- drops the unused file virtualenv.pp which references /N
- drops the puppet-files-* files/classes and all references to them
- ensures that /N is absent using the mount {} type for 32 and 64-bit linux build machines
- ensure /etc/fstab is absent on all macs
Additionally, there's a couple of file updates that need to be done on the masters:
- remove etc/fstab from all mac filestores
- update etc/auto_master on build macs to remove /N references on all mac filestores
Need to give this a quick run through staging still.
Attachment #482596 -
Flags: review?(rail)
Comment 6•15 years ago
|
||
Comment on attachment 482596 [details] [diff] [review]
die nfs die
looks good
Attachment #482596 -
Flags: review?(rail) → review+
Assignee | ||
Comment 7•15 years ago
|
||
Comment on attachment 482596 [details] [diff] [review]
die nfs die
changeset: 237:6f5d7eda6e9d
Attachment #482596 -
Flags: checked-in+
Assignee | ||
Comment 8•15 years ago
|
||
This is landing cleanly. I need to go around to all the ref machines and verify that they pick it up; we'll also need to wait a couple of days to make sure all the slaves have rebooted.
Assignee | ||
Comment 9•15 years ago
|
||
Got the following ref machines:
- talos-r3-{fed,fed64,leopard}-ref
- bm-mini-build-ref
- moz2-darwin10-ref
Still to do:
- linux-ix-ref
- talos-r3-snow-ref
Purposely ignoring (because I highly doubt we'll be cloning new VMs):
- linux-ref-platform
- linux64-ref-platform
Assignee | ||
Comment 10•15 years ago
|
||
(In reply to comment #9)
> Still to do:
> - linux-ix-ref
> - talos-r3-snow-ref
These are done. Filed a bug to get an idea of who is still mounting the share -- should only be buildbot masters and two puppet masters at this point. Want to make sure that there's no slaves mounting it still before we block it at the firewall level.
Assignee | ||
Comment 11•14 years ago
|
||
On second thought, it's probably not important to block this at the firewall level.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•