Hello Kevin

When i click on the link, i get "Invalid request"

Thanks

2013/4/2 emmanuel segura emi2fast@gmail.com

Hello Kevin

Whe i click on the link, i get take "Invalid request"

Thanks

2013/4/2 Kevin Fenzi kevin@scrye.com

...

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

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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure

-- esta es mi vida e me la vivo hasta que dios quiera

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

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

On Wed, 3 Apr 2013 15:00:35 -0400 seth vidal skvidal@fedoraproject.org wrote:

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

Or perhaps that should be:

freezes:

Then we can have whatever script check if we are actually in a freeze (we could set some value for that too)

Just conceptually it reads nicer to me, since those hosts won't always be frozen or not, only during a freeze. If that makes sense.

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?

Sure.

We still need to decide what if anything paste stg and dev are not to freeze, but we can add that as we decide.

kevin

So, circling back to this before next tuesday's freeze, I propose we use the following test to determine if something should be on the 'freezes' or 'doesnt freeze' list:

"If this instance was completely gone, could we have a normal smooth release of Fedora".

Using that I get:

*stg* and *dev* and *.cloud.fedoraproject.org instances are never frozen.

All other machines freeze, except:

arm03* (these arm SOCs are not in builders anywhere yet and are testing/releng/qa).

*comm* This includes:

bastion-comm01.qa virthost-comm01.qa virthost-comm02.qa

These are all community stuff. Secondary arches and qa. We should be carefull, but not sure any of it would be release critical, so I would say it should not be frozen.

darkserver01

We don't depend on darkserver output anywhere in our release process, so I would be ok for it to not be frozen.

fakefas01 hosted-lists01 mm3test people03 packages01 packages02 paste01 paste02 busgateway01 unbound* virthost10 virthost11 virthost12

Would folks like to propose any more? Or propose removing some of the ones I added above?

Speak now. :)

kevin