Skip to content
This repository has been archived by the owner on Dec 13, 2022. It is now read-only.

Patches to OpenStack code #939

Open
odyssey4me opened this issue Apr 23, 2014 · 0 comments
Open

Patches to OpenStack code #939

odyssey4me opened this issue Apr 23, 2014 · 0 comments

Comments

@odyssey4me
Copy link

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant