Fedora 19 Alpha Freeze in effect.

[seth vidal]

On Wed, 3 Apr 2013 12:44:42 -0600
Kevin Fenzi <kevin at scrye.com> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130403/192e478e/attachment.sig>