Date: Wed, 18 Jun 2003 21:57:05 +0200 From: Cejka Rudolf <cejkar@fit.vutbr.cz> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: freebsd-hubs@freebsd.org Subject: Re: DRAFT - Release Guide Message-ID: <20030618195705.GA3899@fit.vutbr.cz> In-Reply-To: <20030614014358.GA29321@electra.cse.Buffalo.EDU> References: <20030614014358.GA29321@electra.cse.Buffalo.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
Well. Uff :o) So, here are my proposed modifications: Ken Smith wrote (2003/06/13): > ftp-master: the master distribution server, data is initially loaded > here ftp-master: Primary non-public data server. Access is allowed just for ftp-master.xx and Tier-1 servers, so ftp-master is never overloaded. ftp-master.xx: Secondary non-public data servers. Access is allowed for Tier-1 and Tier-2 servers. > Tier-1 server: official FreeBSD mirror site that pulls data from > ftp-master Tier-1 server: Official public FreeBSD mirror site synced from ftp-master or ftp-master.xx. Mirror operator is well known and is well responsive (let's say in 3 days, but not very often longer vacations should be allowed too :o). There is well-known minimal required disk space for mirrors and any increase has to be announced sufficiently before any change (year or so - exception would be with known donations :o). Mirror has to carry all data from ftp-master. When there are files/directories with none permissions for others, mirror site must not allow downloading of these files. Furthermore, mirror offers for ftp-master special services using net/tier1 port (I have used snmp in following real examples, but port does not exist yet - this is just draft ;o), so anybody on ftp-master can check free disk space and/or existence of observed files on all Tier-1 mirrors: # ./info.sh d ftp.cz.FreeBSD.org: 29084 # MB ... # ./info.sh releases/i386/ISO-IMAGES/5.1/5.1-RELEASE-i386-disc1.iso 645169152 ftp.cz.FreeBSD.org: Yes ... # ./info.sh releases/i386/ISO-IMAGES/5.1/5.1-RELEASE-i386-disc1.iso 1 ftp.cz.FreeBSD.org: No (645169152) ... It is possible to imagine other services. When another service is needed, port net/tier1 is updated and operators are required to update this port on their mirror sites. I can imagine stats about server load and stats about downloads of observed files, so that central site with all interesting stats can be created. Another service would be setting file permissions directly from ftp-master on all Tier-1 servers, but we would need to think about interoperability with cvsup update method and its cache file - remove it or edit it? And what to do if cvsup is currently running? Another idea: To be able to push information, that update should be started. However, I think that it is hard for realization, because there are several people and robots updating files on ftp-master and updates overlap and can be arbitrarily long, so I think that required updates every 3 (2, 1) hours would be sufficient (if previous update has been done). > Tier-2 server: official FreeBSD mirror site that pulls data from a > Tier-1 server. Not all Tier-1 servers feed Tier-2 servers (we would > like to set up more that do). Tier-2 server: Official public FreeBSD mirror site synced from ftp-master.xx (non-public) or Tier-1 server (public). There are well-known restrictions, why it could not be Tier-1 server, for example it has just well-defined subset of ftp-master data, it is too slow, it does not have fresh data, operator is not responsive, site is not reliable... > have a decent network connection between them. So taking worst case > scenarios into account it can be three days before large amounts of It depends on many factors, so let's offer the possibility to check update status of all Tier-1 servers directly from ftp-master and announcements can be done based on real state of things. > data can propagate from ftp-master to a Tier-2 site. This situation > gets worse if there is something causing a larger than normal network > load at the time. I think that it would be better to have smaller number of reliable mirrors, that big number of unreliable ones, so I propose do not check state of Tier-2 mirrors - just reduced set of Tier-1 mirrors. > Mirror Sites is that there be a day or two worth of advanced notice > (weekdays) that the Beta is coming AND a reasonable estimate of how > much disk space will be needed. > ... > The size estimates should be given for both the -RELEASE tree > and the new package trees. > ... > this point and find/report a bug that would stop the release). If > Beta-1 needs to co-exist with Beta-2 and so on then size estimates > will again be needed a day or two before Beta-2 gets posted on > ftp-master. I think that it is needed just for very small number of people (two? three?) and it is somewhat annoying for people updating on ftp-master. If people on ftp-master can check free disk space on mirrors themselves, they can always do the right thing - for example warn on hubs@, so that situation with particular mirror can be solved. In other case, mirror can be moved from Tier-1 to Tier-2 class. > The -RELEASE stuff should be posted to ftp-master three days before > Release Day, with the permissions set so that access by "other" is I think that it is really hard to say if it would be one, two, three or more days. What about network traffic jams? Or upgraded internet lines? ;o) Furthermore, if I were release team, I would be frustrated from this - I want to announce new release as soon as possible, but I have to wait so many days. As I proposed above: Let's give people on ftp-master the possibility to check state of all interesting mirror sites, so that they can do announcements, whey they think it is right time. The transition to the new policies would be simple: Let's say date, when access to ftp-master is stopped to all sites, which does not satisfy all conditions above. Comments are welcomed ;o) -- Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030618195705.GA3899>