Do you want to use OpenStack for production ? But OpenStack is not a product, it is community. Why do you need to use product ?
Because you need to control dependencies and functionality. Dependencies management it is a part of release management. Each product has life management cycle and release management is part of this cycle.
There are lot of products built from OpenStack's components. Many companies provide service support for solutions and products.
Each product built from OpenStack has:
- release cycle integrated with release cycle of all used OpenStack's projects
- supported configuration/configurations
- - list of used OpenStack's projects/components
- - - each OpenStack's project has own
- - - - set of supported features
- - - - set of supported options
- - - - set of dependencies
- deployment automation
You can choose product . And usually it is possible to request changes/support of new features/options from your service provider, from someone who support release cycle of product.
If you need to have more flexibility, you need to build your own product based on OpenStack's projects. This product will be integration solution. And to support release cycle you will need to build CICD system.
Main components of this CICD system:
- CI lab automation: it should support hundreds of OpenStack deployment in a day for testing.
- test automation: functionality of OpenStack components and maintenance use case like "fresh install" or "upgrade".
- datastore for CI and CD events: promotion of new version from dev to prestage env; for compatibility reports.
Output from CICD system is information about compatibility between dependencies and functionality ( features, options, conf).
Main big challenge here , even you did not start develop any code line, is integration with big open world. Because any time any where some changes can happened and functionality will be broken.
It is very huge risk for anyone who maintain real product for real end-customers ( many companies who develop products around OpenStacks are integration/consulting/software companies who develop solutions for service providers )
What we can do to manage this risk ? We should build CICD system which should collect data to support release process , to support delivery in production. This CICD system should operate very near to real time mode, to continuous mode - it means operate periodically with very small period of time ( to find broken dependencies/feature as soon as possible). It should give your time to react and to fix issue. It should give you ability release you next release without delays and as a result it should save your business from break.
Few important notes about internal CICD system: 1) it should be integrated with external CICD systems: for example everyone is using linux, and linux-based products like Ubuntu, Redhat, Suse. And OpenStack it is just integration on top of system tools. 2) deployment automation is important part of CICD, but it is independent component with own set of dependencies/functionalities 3) test automation is important part of CICD: your need to collect data/all metrics about functionalities/dependencies, etc 4) open technologies and open source, it is a great things because help to collaborate, evaluate. That is why outputs from your CICD system can help people in open world and it is nice to share/contribute outputs from your CICD system ( data, bug reports) to open source community.
I'm very appreciated to everyone with whom I've already discussed my thoughts and I will be appreciated to everyone for any thoughts/feedback.
No comments:
Post a Comment