With the apache2 cookbook rewrite from definitions to custom resources almost complete, we're looking for ways people want to configure apache2 in the future.
Do you:
Use custom templates
Always add but disable modules
Need to pass in very specific configuration to templates
Not really know what a custom resource?
Use the recipes in the cookbook a lot? (we’re looking at dropping more recipes in the future)
Think a default in the cookbook is dangerous?
If any (and more) of the above look right we’d love some feedback on github:
Then please call the new cookbook "apache3", since it apparently won't be backwards compatible. We went through extensive rewrites with the "yum" and "tomcat" and "mysql" cookbooks that were so painfully incompatible with other, stable cookbooks that they broke production systems and required users to maintain multiple versions of the "upgraded" cookbooks to maintain compatibility.
On the surface that would look like massive criticism of this work. But in reflection this is really helpful, thank you.
I've not said anything about removing/breaking backwards compatibility but I guess this was assumed with the word rewrite in this post's title?
We're aiming for backwards compatibility with this work wherever possible. All the same resources work, except they may have been renamed, for example apache_module is now apache2_module.
The hope for this post and the attached issue on apache2, is to gather current configurations (with sensitive details taken out) and put them into integration and/or unit tests so that we minimise disruption.
That being said there is some functionality that the definitions were providing that make it difficult to port to custom resources.
I added a some notes to the git pull request. In my opinion, the pull request is too big, it has many small behavioral changes that could be submitted independently and more safely. It's often very tempting to make a complete set of structural changes, while fixing one or two individual issues. But it's risky.
You don't seem to have done the sort of structural changes that made the mysql, yum, and tomcat upgrades so painful, which is good. But the change is updating more than 200 files: It would take me, at least, more time to analyze all of them and their full extent than I can spare right now.
The cookbook should still be called apache2 and a simple major version increment is all that is required to break back compat and still be semver compliant. I think that creating another name, that isn't even relevant to the name of the software product being configured is more onerous for everyone involved.
It's also worth pointing out that nobody is obligated to upgrade to the next major version either.