Greetings. we are now in the infrastructure freeze leading up to the Fedora 19 Alpha release. This is a pre-release freeze. Please see: https://fedorahosted.org/fedora-infrastructure/browser/architecture/Envir... Anything in the Pre Release freeze box is frozen until 2013-04-16 (or later if Alpha slips). This means there should be NO puppet changes to any hosts in there (including global ones) without signoff of the change from at least 2 folks in sysadmin-main and/or release-engineering. Thanks, kevin _______________________________________________ infrastructure mailing list infrastructure(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Greetings. we are now in the infrastructure freeze leading up to the Fedora 19 Alpha release. This is a pre-release freeze. Please see: https://fedorahosted.org/fedora-infrastructure/browser/architecture/Envir... Anything in the Pre Release freeze box is frozen until 2013-04-16 (or later if Alpha slips). This means there should be NO puppet changes to any hosts in there (including global ones) without signoff of the change from at least 2 folks in sysadmin-main and/or release-engineering. Thanks, kevin _______________________________________________ infrastructure mailing list infrastructure(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure

On Tue, 2 Apr 2013 09:13:34 -0600 Kevin Fenzi <kevin(a)scrye.com&gt; wrote: > Greetings. > > we are now in the infrastructure freeze leading up to the Fedora 19 > Alpha release. This is a pre-release freeze. > > Please see: > https://fedorahosted.org/fedora-infrastructure/browser/architecture/Envir... > http://git.fedorahosted.org/cgit/fedora-infrastructure.git/plain/architec... That link should work. -sv _______________________________________________ infrastructure mailing list infrastructure(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure

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/architec... 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

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.