[2938] in SIPB_Linux_Development
Re: Hesiod information for systems installed with our installer
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Aug 28 16:33:38 2000
To: Greg Hudson <ghudson@MIT.EDU>
Cc: linux-dev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 28 Aug 2000 16:33:14 -0400
In-Reply-To: Greg Hudson's message of "Mon, 28 Aug 2000 16:05:15 -0400"
>>>>> "Greg" == Greg Hudson <ghudson@MIT.EDU> writes:
>> I had assumed that we could install local cluster information
>> for machines without Hesiod, but this is a bad idea.
Greg> Couple of things you didn't appear to consider:
Greg> * We (Athena) kind of like to have a central list of
Greg> machines we might screw over by making various changes to
Greg> the release. We might be able to maintain such a list in
Greg> other ways, but Hesiod has some nice advantages. Unless
Greg> people start using cluster.local a lot.
I agree we really want to get people to have Hesiod clusters. My
concern is that we also want to avoid having machines not update
because the user hasn't followed through and set up Hesiod. If we
don't have the default action be to auto update unless the user takes
steps to disable the updates, I am concerned that we may increase
support load. Perhaps I am too paranoid about this.
Greg> * The Hesiod method gives us a lot of flexibility to
Greg> make update policies on the fly. If Hesiod information
Greg> contained no version information, and the machine instead
Greg> had local state saying whether it takes alpha or beta
Greg> releases or whatnot, then we couldn't auto-update arbitrary
Greg> groups of machines on different nights, for instance.
This is an interesting point I should consider if I try to make a
statement stronger than the current version-dependent mechanism
bothers me and something to take into account if I try to come up with
an alternate proposal. But I agree that having people in Hesiod
whereever we can get the users to do so is the best solution, so at a
practical level this point doesn't matter.
