On Wed, 3 Apr 2013 12:44:42 -0600 Kevin Fenzi <kevin@xxxxxxxxx> wrote: > Sorry about the broken link there. ;) > > So, we had a bit of discussion on IRC the other day around this. > > Our current freeze document is: > > http://git.fedorahosted.org/cgit/fedora-infrastructure.git/plain/architecture/Environments.png > > But thats an image, so it has to be manually edited. > It's missing a lot of hosts we have added or changed over time. > It's not fully clear what the critera is for a host to be in freeze. > > Toward that end, I'd like to have a discussion about that, and then we > can figure out a better and more automagic way to display what hosts > are in freeze. > > So, some background: > > Why do we do freezes? The reason is that we want to make sure to only > make minimal or well reviewed changes before Fedora releases. We don't > want something we change to disrupt a release in any way and having > fewer changes and changes we review helps do just that. > > Currently pre-release freezes don't cover as many machines as final > release freezes. The thought there is that pre-releases don't have as > many consumers and not as much changes from other teams around them, > so we can make changes to fringe machines without disrupting them as > much. > > So, a first cut at critera: > > A machine will be frozen if any of the following are true: > > 1. The machine is needed in the package lifecycle. That includes: > source code checkin, build system, signing, updates system, > distribution/mirroring system. > > Rationale: We need to build and distribute packages for the release. > > 2. The machine is needed to allow functions in 1. This includes: > database servers, virthosts with guests in set 1, login/authentication > to updates/buildsys, dns servers, mailing list servers, etc. > > Rationale: if dns breaks, no one can download our release, if > login/auth fails, package updates don't work, etc. > > 3. The machine is needed for monitoring/disaster recovery for 1 or 2. > This includes: backup servers, noc01/02, lockbox01 with > puppet/ansible. > > So, you may note that this covers a large number of machines. :) > > I think it might be more useful for us to just assume that in a > freeze, "all" machines are frozen, except for ones we specifically > exempt from freeze. > > * All of staging shouldn't be frozen. So, if it has *stg* in it's > hostname it's ok. > > * All of dev should never freeze. So if it has '*dev*' in it's > hostname it's ok. > > What other machines should we say aren't frozen? > Or should we just say 'stg' and 'dev' and thats it? (That would make > it simple to know, but make it harder to make changes on fringe > machines). > > What about things like: > > ask > packages01/02 > people03 > paste01 > busgateway01 > hosted-lists01 > openid01/02 (if hosted uses this does that make it more frozen?) > darkserver01 > unbound* > value03 > > Thoughts? > > kevin > Well - simplest thing, imo, would be to add a host_vars for each host which is not frozen. something like: inventory/host_vars/hostname --- frozen: false and then in inventory/group_vars/all --- frozen: true I believe the variable precedence lets host vars trump global vars. easy to test and we should be able to easily do an inventory query to dump the frozen/unfrozen hosts? Want me to do a simple test of it? -sv
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
