From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 10:51:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FB08106566B; Tue, 22 Feb 2011 10:51:09 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1F48FC19; Tue, 22 Feb 2011 10:51:09 +0000 (UTC) Received: from [210.177.209.182] (port=13139 helo=[192.168.1.151]) by postoffice.vicor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) (envelope-from ) id 1PrppZ-0004JS-V4; Tue, 22 Feb 2011 02:51:08 -0800 Mime-Version: 1.0 (Apple Message framework v1081) From: Devin Teske In-Reply-To: <201102220103.20158.josh@tcbug.org> Date: Tue, 22 Feb 2011 02:50:54 -0800 Message-Id: References: <4D35CFFB.3010302@freebsd.org> <201102211612.51233.josh@tcbug.org> <201102220103.20158.josh@tcbug.org> To: Josh Paetzel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 0d916604628b474728ef7f444882548c X-Scan-Host: postoffice.vicor.com X-Mailman-Approved-At: Tue, 22 Feb 2011 12:42:52 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bruce Cran , freebsd-sysinstall@freebsd.org, freebsd-current@freebsd.org, Nathan Whitehorn , freebsd-arch@freebsd.org Subject: Re: FreeBSD Installer Roadmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 10:51:09 -0000 On Feb 21, 2011, at 11:03 PM, Josh Paetzel wrote: > On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote: >=20 >>=20 >> Really, the crux of the issue is that our organization is **just = now** >> migrating off of FreeBSD-4 (yes, it's true... there are over 1,000 >> FreeBSD-4.11 machines running in production at this very moment = spanning >> the entire United States, parts of India, and parts of the = Indo-pacific >> rim). Worse? We just added yet-another 200+ to those ranks in the = past 2 >> months. >>=20 >> My hat is off to you sir... as I envy your position that you can be = so >> free-moving. We are encumbered by entrenched methods and do not have = the >> luxury of trying new things for the sake of change (case in-point, = since >> bsdinstall brings nothing new to the table that we rely upon, it = truly >> would be change for the sake of change in our organization). >>=20 >> Fin de dialectics. >>=20 >>=20 >>=20 >>=20 >> -- >> Cheers, >> Devin Teske >=20 > Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't = being=20 > added to it, and the featureset that sysinstall supports is pretty = much in=20 > line with the featureset in 4...no ZFS, no geom_*, etc etc etc. >=20 > On the other hand, maintaining sysinstall for the next N years of new = FreeBSD=20 > releases seems hard Actually, it's trivial to anyone that has mastered release engineering = (see release(7) and the handbook). > , when it's already missing features compared to what=20 > FreeBSD supports, That's the operative word here ("supports"). Lord help us when that = changes to "requires" (that is to say, if/when the FreeBSD kernel = becomes legacy-free with respect to supporting fdisk/disklabel = partitioned disks). > and that's likely to continue to grow. We've yet to see a "must have" technology that would require us to shun = sysinstall (as explained earlier, we have no desire whatsoever to boot = from ZFS, gmirror, geli, GPT, or anything else missing from sysinstall). One such possible motivation would be if we needed to create a boot = partition that exceeds 4TB (the limits of MBR partitioning versus GPT). = I just don't see that happening (workstations, servers, pedestals... why = would we ever need >8GB for the operating system? all production data is = being stored on enterprise class devices such as the NEC-D210, and being = backed up with tapes such as LTO; In our organization every machine is = expendable and we have disaster recovery procedures for any/all = failures). >=20 > I totally agree that for internal use, migrating thousands of lines of = code=20 > makes no sense whatsoever, especially if sysinstall meets your needs = and you=20 > don't care about the functionality it doesn't have. Exporting that to = the=20 > community seems to be a questionable use of resources. >=20 > I'm no stranger to large deployments. With my ${WORK} hat on we can = install a=20 > thousand FreeBSD systems in a week. In my 16+ years of involvement = with=20 > FreeBSD I've written three automated installers...quite frankly, = ditching=20 > sysinstall for that happened really fast. Good work. However, it's a shame that you found the need to ditch sysinstall. We = found no such need and have created an automated network installation = process literally on the assembly line in a factory the size of a = football stadium -- responsible for churning out thousands of machines = per year with FreeBSD-4.11 pre-installed before they arrive on-site (all = using sysinstall). The hardware gets assembled to-spec, slides down an = assembly-line, a technician jacks power, network, video and keyboard to = the box, netboots it by pressing F12, waits 5 minutes for the screen to = finish installation, powers it off, and slides it down the line. > I do admit to being a tad curious where you find systems that can run = FreeBSD=20 > 4 at this point. We're installing FreeBSD-4.11 onto modern systems, including: Intel Server Chassis SC5299 Intel Server Chassis SR2500 just to name a couple. Albeit, we've back-ported many drivers, such as mfi(3) from RELENG_6 to = support the LSI MegaSAS controller. We're no stranger to putting even the Operating System on Life Support = for as long as it takes for our customers to bolster their budgets for = an integrated upgrade strategy. We have a very small yet largely talented group of individuals = (including myself) within our organization that quickly and efficiently = remediate lost functionality required to maintain hardware compatibility = simply because our customers cannot stomach upgrading the OS every = 18-months (or whatever the life-cycle may be). We can't be forcing our = customers to upgrade their entire organization everytime the OS can't = boot from some new controller -- not when adding the lost functionality = into the OS is only a matter of a couple weeks work (at most). So in earnest, I should have clarified that despite running FreeBSD-4.11 = on thousands of machines... it's actually a highly customized kernel = _and_ install process that allows us to run on modern hardware. > A single socket intel shows up as 8 or 12 CPUs these days,=20 > more than enough to tie 4.x into knots. Add in disk controllers, = NICs, ACPI=20 > (modern systems use that for nearly everything it seems) and suddenly = an=20 > installer seems the least of the concerns. You are absolutely right. Everything about FreeBSD-4.11 is on = life-support in our enterprise. The kernel/installer has pieces from = RELENG_6, RELENG_7, and even RELENG_8. Life-support is our specialty as = our clients demand it. When suppliers decide to EOL certain hardware, we = simply back-port the necessary changes to support the new hardware. When = FreeBSD EOL'd 4.11, that by no means gave us a right to go mandate that = our customers immediately upgrade (which would cost potentially millions = of dollars). >=20 > I suppose my last question is along the lines of, "If adding = geom_mirror=20 > support to sysinstall was easy, why has it been 6+ years since gmirror = made=20 > it's appearance in FreeBSD and you still can't create or install to a = gmirror=20 > with sysinstall?" In enterprise business we rely on hardware RAID. If software RAID such as gmirror was an acceptable solution in our = Enterprise, I'd have personally added it to sysinstall years ago. >=20 >=20 > --=20 > Thanks, >=20 > Josh Paetzel -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ = L++++$ E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ = b+>++ DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <-