[1357] in athena10
Re: Apt repository layout
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Sat Mar 7 14:01:17 2009
Cc: Evan Broder <broder@mit.edu>, Tim Abbott <tabbott@mit.edu>,
debathena@mit.edu
Message-Id: <0902A9EE-2996-4ACC-8F74-086B7924B575@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Greg Price <price@mit.edu>
In-Reply-To: <20090307174449.GA3488@cross-cap.csail.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sat, 7 Mar 2009 13:51:37 -0500
On Mar 7, 2009, at 12:45 PM, Greg Price wrote:
> SIPB office heads should use -proposed and run -auto-update; in
> fact, they
> should probably run -managed (or whatever name it gets). That will
> provide some testing. If the staff involved with Debathena also run
> -auto-update and use -proposed on their desktops, that probably
> suffices.
I think this is a good idea.
This essentially mirrors the functionality we have now with Athena 9
"alpha", "beta", and "public" clusters. Since we haven't had a major
release in 4 years, the existence of the "alpha" cluster may have
fallen off people's radar. Basically, machines in the "alpha" cluster
get a bleeding release when we do a major version update.
Historically that was 1 OLC machine, 1 SIPB machine, some developer
machines and a few other random machines. When we're not in the
process of doing a major release, alpha machines behave like beta
ones. The "beta" cluster (aka "dev cell machines") gets updates
before they go out in the field to ensure that things aren't broken.
Historically, this was another OLC machine, another SIPB machine, and
desktop machines of Athena folk in I/S (&T) (me, alexp, wdc, boojum,
ops folks, etc).
So, if we go this route, I would in fact propose that we add
clusterinfo data to the alpha and beta linux clusters, which would
cause them to take -development and -proposed, respectively.
Obviously, we'd want to notify maintainers of existing machines prior
to this change, and allow them to move into different clusters prior
to installing Debathena. But I think using our existing pools of
machines (and updating membership of those pools as needed) is the
best way to ensure that new features get a lot of testing in the field.
-Jon
(If you're interested in seeing cluster membership, "qy -s gmcm \*
alpha-linux" and "qy -s gmcm \* beta-linux" are the relevant moira
queries.)
