draft of talk proposal for OpenStack summit

Proposed Presentation Title*: Data-driven release decisions for your private IaaS cloud.

Abstract:
Are you using OpenStack in production?
Do you need to manage feature list delivered in production by yourself?
It sounds like you are working on your own product which is based on OpenStack's community and maybe on some existing OpenStack's distribution. If you really want to be flexible in release management for your OpenStack production solution, then you need to develop and maintain product.
Let's assume for beginning that you are using some OpenStack's distribution and you are not planning to maintain independent version of source code.You just want to control you feature list in production, support change management process and support few development teams which are working on new features for production.
"Opensource","RM", "CI", "CD": all these words together for your own little cheese shop link1[https://www.youtube.com/watch?v=cWDdd5KKhts] link2[http://www.space.com/10459-wheel-cheese-launched-space-private-spacecraft.html].
This talk is about internal implementation of few CICD components and about what do you need to support few regular releases and few change management incidents in year.

What is the problem or use case you’re addressing in this session?
The term "production environment" means that you are using approach based on products in your business operations. And infrastructure as a service can be delivered by using solution that will be built from OpenStack's components. There is one thing that can help to integrate your business operation model and open source community model of software development. This thing is the product that should be developed and maintained. It should be compiled from open source components, but it should have own release cycle. This release cycle should be based on release cycle of open source components and should help integrate business requirements for new features and development model ( release cycle, methodology etc) of different open source projects.

What should attendees expect to learn?

This talk will be about product example that  can be built from OpenStack's projects. What do you need to support release cycle? How CICD automation can help? 

Also it can be interesting to learn about CICD automation as a product: data structure/API design session, components and api calls.

Why should this session be selected?

This session should be selected if you are interested to know what are the relations between CICD, product development and using open source technologies. How open discussion can help collaborate and integrate? Release management as final integration point. Because delivery is a process that can integrate.

There are different people, different ideas, different approaches, different experience, difference between short term strategy and midterm strategy, huge gap between long term strategy and every day routine life, gap between future and present. Open discussion in open source community can help to present different things in formal way. Formal logic, it is an integration point. Public form of discussion, it is validation method. Talk on summit should help to share experience and open discussion can help to verify problem statement and implementation approach.

Working on continuous integration for "open source" technologies and software as knowledge.

Integration solutions are based on integrity of teamwork, integrity between different people/different teams. You should have integrated vision on goals, problems, solutions, pros and cons, estimates of value-ability, efforts.

why do I believe that " open source " can create added business value ?

Work with "open source" means that you are working in open space, in open world. Not only each line of code is open, but all questions are open. What is  the problem definition, what are the possible solutions ? pros, cons ? Why did you try to propose new implementation but not fix for existing ? Open discussion, it is very expensive thing but it can be very valuable because open discussion helps to validate. To validate approach, use case, feature, hypothesis, ideas.  Only if you can organize open discussion you can attract new users,  power that can validate, verify, improve. Of course sometimes it can be too expensive. But in real life you should realize that there is no absolute private world/private discussion, everything will be merged in some open discussion and will be part of open world.

It is business question, because it is about open market. And it is about special competitive advantage on market: you are open because you are ready for competition and you are ready for competition because you are the best and the fastest.

Some people thinks that openness is not secure and there are security cons. But I believe that security professionals can confirm that openness helps be more secure and helps have better security.

Are you ready for evaluation, verification of your business ideas, of you technical solutions ? Do you believe that your solutions are efficient,  competitive,  secure ?  What is the value of such questions ? I believe that your customers are your investors and your investors are you customers. It is big team of players in big game. And game is creation of knowledges and maintenance of knowledge models in actual state.

levels of evaluation and long-term strategy

Private knowledge it is such knowledge that are not ready for open evaluation.   Not ready for open evaluation in your team, in your department, in your company,  on market, in community. And important thing that in science, for example, huge value and big result is achieved when you have proofed failure of validation. "Which way does not work " A lot of projects were failed because they tried to keep private such type of knowledges.

few notes about product compiled from opensource on example of OpenStack, release management and CICD support.

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.

Brief summary for myself about my professional experience

Brief summary for myself about my professional experience:
- software engineer ( telecommunication company: C#.NET refactoring, re-engineering, business process automation, system integration; 2 years )
- project manager  ( telecom company: business process automation, integration SOA/Soap, 2 years)
- team leader (telecom company: production delivery, system integration Sun Microsystems and opensource technologies, Solaris Containers, LDOM, VMas a service, Storage as a service, 4 years)
- software engineer ( GridDynamics: 1) OpenStack deployment automation RedHat, Cisco UCS; 2) Hybrid cloud OpenStack/Amazon AWS/Cisco Intelligence Automation 3) CICD solutions ( Hadoop,ATG, OpenShift, Amazon/Rackspace/OpenStack); total 4 years) 

Knowledge, Integrity, ....

Imho. Everyone can create/develop software.

There is no special requirements. In general it is true for me.  But there are some details important for me.  I think about software as about special form/state of knowledge. If you have some knowledge you can put it in software. Maybe I would like to say even that you should put it in form of software. Why "should" ? To verify. Of course there are different ways to verify different knowledges and of course it is not possible to verify  any knowledge by using software. But I believe that there is no software without knowledge in it and there is no software with knowledge inside that will not verify knowledge by execution.

It is some kind of concept and this concept it valuable for me. Maybe the point of view is important for me because last  years I was working with integration of/between software systems.

Different types of integrations:  "Concordia, Integritas, Industria"

1. I've started from  refactoring/rewriting software systems. 
2. Then I was trying to integrate data workflows/sequences of  operations in team collaboration/ business processes, I was trying to create integrated view on how software system will organize communications/collaboration between people and will keep integrity of data.
3. I was working on integration between software systems with SOA-like design through SOAP/REST and ESB/message bus patterns.  
4. Also I was working on trying to created integrated production system by using components from open source community.
5. Last time I was working around integration on level of source code, CI for software development.

Yes. It is some kind of attempt to achieve internal integration and recompile my working experience around few basic concepts.

nanos gigantum humeris insidentes

I've create this blog sometime ago for notes about notable things in my professional area.

First note was about people who taught me in university.   And this note was not finished yet because I want to  continue to add notes about my teachers / student colleagues / work colleagues .  And because my studying is not finished. I would like to collect and keep in mind details about everyone who spent some time, was collaborating with me and invest own time, knowledge, feelings in what I have as an engineer, professional worker, serviceman (servant).

I'm very appreciated for everyone with whom I was actively living/ working/ collaborating/intersecting from time I was born.

"If I have seen further it is by standing on ye sholders of Giants."  Isaac Newton
"nanos gigantum humeris insidentes"    https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants