This looks good to me.

The procedure is straightforward and merging from staging back into production is simple. When there's no config changes, there's nothing to be done in puppet which is also nice.

The only drawback is the first time someone needs to push configs to staging they may not know what to do at all. Might be alleviated with a modules-staging/README that explains things.

-Toshio

On Tue, Mar 13, 2012 at 02:47:32PM -0600, Kevin Fenzi wrote:

We agreed at fudcon (well, before then really) that we didn't like some of the current setup with staging and we were going to redo it. We came up with some plans at fudcon and I have been working on implementing those this week. ;)

So, in the new staging world order how will things work?

EVERYTHING will be in the master puppet branch.

There is a 'staging' environment. This should be set on any nodes that are being used for staging. (ie, "$puppetEnvironment='staging'" should appear at the top of any node being used for staging things.

Workflow for staging changes:

1. If you don't need to make any puppet related config changes, don't

do anything. (ie, a new version of an app that uses the same config files, etc). Just update on the host and test.

2. If you need to make puppet changes in the module of the application:

• cp modules/$yourmodulename modules-staging/$yourmodulename
• git add modules-staging/$yourmodulename; git commit -a
• make changes you need to modules-staging/$yourmodulename
• test, make more changes to it, etc.
• diff -Nur modules-staging/$yourmodulename modules/$yourmodulename and check your changes for sanity.
• rsync -avr modules-staging/$yourmodulename modules/$yourmodulename
• git rm -rf modules-staging/$yourmodulename

3. If you need to make changes outside of your module:

• Make use of files ending with .staging (see resolv.conf in global for an example). So, if there's persistent changes in staging from production like a different config file, use this.
• Conditionalize on environment:

if $puppetEnvironment == 'staging' { yourcode } else{ productiononly code }

• These changes can stay if they are helpful for further testing down the road. Ideally normal case is that staging and production pull from the same module unless there's active testing of changes being made (ie, there is no modules-staging/ unless something is being staged.)

Now, hopefully this isn't too much burden on app folks or those who test with staging. If so, please scream now. ;)

Additional things we can do:

Since all the 'in progress' changes are in modules-staging, we can run a script (once a week?) to list those modules and ask 'hey, are you still testing this? can it be nuked or merged?' Perhaps with a attached 'diff -Nur modules-staging modules' attached?

Does this work for everyone? If so, I will make the change in the next few days and get it done with. I need to work on app01.stg/app02.stg/proxy01.stg. They will need some config files that are for staging, but otherwise shouldn't be too bad.

kevin

---

infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure