You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 13, 2022. It is now read-only.
This is an idea for discussion, rather than a bug/issue.
There have been times within the cookbook releases where there has been a need to patch OpenStack code in order to resolve a known bug. While the OpenStack code-base is in active development the bugs are generally resolved and the patches eventually merged. However when the code-base is no longer actively in development the bug generally remains in place and we end up with production deployments that have known issues. Our choices as deployers are to live with it, upgrade the environment to a later version (which has the fix merged) or to maintain patches in our cookbooks. None of these are great choices to have to live with.
I've been considering what alternatives we have in order to keep OpenStack code out of the cookbooks, but still have the flexibility to patch prior to the fix being in the upstream packages and also to have the capability to patch when the upstream code is no longer under active development.
The strategy that comes to mind as being the most practical is to have a fork of the upstream repo and a toolchain in front of it that automatically packages the code into the rpm and deb files required for deployment whenever a new merge takes place. Merges into the fork would require the completion of successful unit and integration tests and the release of the deb/rpm into the appropriate production repo would require a successful Chef-based deployment and its usual tests, then also approval by a QA team.
The deployment cookbooks can then simply just add the extra repo which provides the packages, making them available for upgrades whenever they need to be actioned.
While this does involve taking on some work and perhaps also some technical debt, the flexibility to backport fixes and features as we want them far outweighs the technical debt. It also nicely separates the deployment code from the application code.
Thoughts?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is an idea for discussion, rather than a bug/issue.
There have been times within the cookbook releases where there has been a need to patch OpenStack code in order to resolve a known bug. While the OpenStack code-base is in active development the bugs are generally resolved and the patches eventually merged. However when the code-base is no longer actively in development the bug generally remains in place and we end up with production deployments that have known issues. Our choices as deployers are to live with it, upgrade the environment to a later version (which has the fix merged) or to maintain patches in our cookbooks. None of these are great choices to have to live with.
I've been considering what alternatives we have in order to keep OpenStack code out of the cookbooks, but still have the flexibility to patch prior to the fix being in the upstream packages and also to have the capability to patch when the upstream code is no longer under active development.
The strategy that comes to mind as being the most practical is to have a fork of the upstream repo and a toolchain in front of it that automatically packages the code into the rpm and deb files required for deployment whenever a new merge takes place. Merges into the fork would require the completion of successful unit and integration tests and the release of the deb/rpm into the appropriate production repo would require a successful Chef-based deployment and its usual tests, then also approval by a QA team.
The deployment cookbooks can then simply just add the extra repo which provides the packages, making them available for upgrades whenever they need to be actioned.
While this does involve taking on some work and perhaps also some technical debt, the flexibility to backport fixes and features as we want them far outweighs the technical debt. It also nicely separates the deployment code from the application code.
Thoughts?
The text was updated successfully, but these errors were encountered: