Closed Bug 597913 Opened 15 years ago Closed 14 years ago

stop mounting NFS on slaves/masters

Categories

(Release Engineering :: General, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

References

Details

Attachments

(1 file)

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.
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.
Is bug 597912 intentionally closed ?
No. I cleared the flags on it.
I'll be doing this, still don't have an ETA.
Assignee: nobody → bhearsum
Attached patch die nfs dieSplinter Review
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 on attachment 482596 [details] [diff] [review] die nfs die looks good
Attachment #482596 - Flags: review?(rail) → review+
Comment on attachment 482596 [details] [diff] [review] die nfs die changeset: 237:6f5d7eda6e9d
Attachment #482596 - Flags: checked-in+
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.
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
(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.
Depends on: 605287
On second thought, it's probably not important to block this at the firewall level.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: