Re: FreeBSD Installer Roadmap

From: Devin Teske <dteske_at_vicor.com>
Date: Tue, 22 Feb 2011 02:50:54 -0800
On Feb 21, 2011, at 11:03 PM, Josh Paetzel wrote:

> On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote:
> 
>> 
>> 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.
>> 
>> 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).
>> 
>> Fin de dialectics.
>> 
>> 
>> 
>> 
>> --
>> Cheers,
>> Devin Teske
> 
> Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't being 
> added to it, and the featureset that sysinstall supports is pretty much in 
> line with the featureset in 4...no ZFS, no geom_*, etc etc etc.
> 
> On the other hand, maintaining sysinstall for the next N years of new FreeBSD 
> 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 
> 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).


> 
> I totally agree that for internal use, migrating thousands of lines of code 
> makes no sense whatsoever, especially if sysinstall meets your needs and you 
> don't care about the functionality it doesn't have.  Exporting that to the 
> community seems to be a questionable use of resources.
> 
> I'm no stranger to large deployments.  With my ${WORK} hat on we can install a 
> thousand FreeBSD systems in a week.  In my 16+ years of involvement with 
> FreeBSD I've written three automated installers...quite frankly, ditching 
> 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 
> 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, 
> more than enough to tie 4.x into knots.  Add in disk controllers, NICs, ACPI 
> (modern systems use that for nearly everything it seems) and suddenly an 
> 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).


> 
> I suppose my last question is along the lines of, "If adding geom_mirror 
> support to sysinstall was easy, why has it been 6+ years since gmirror made 
> it's appearance in FreeBSD and you still can't create or install to a gmirror 
> 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.


> 
> 
> -- 
> Thanks,
> 
> 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_at_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+++_at_$ UB++++$ P++++_at_$ L++++$ E-
W+++ N? o? K? w_at_ O M++$ V- PS+>++ PE_at_ 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 <-
Received on Tue Feb 22 2011 - 09:51:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:11 UTC