Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what problems need to be considered in adding Go language to OpenStack development". In daily operation, I believe that many people have doubts about what problems need to be considered in adding Go language to OpenStack development. The editor has consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts that "what problems need to be considered in adding Go language to OpenStack development"! Next, please follow the editor to study!

During the cycle of the new version of Newton, the Technical Assessment Committee received a proposal to use Go as the official development language for OpenStack. There was a lot of discussion that followed, and here we will not repeat the process, but only the results of a few points of discussion.

The resolution temporarily refuses to allow Go as an official development language, but says it can be discussed in the future. I think Go may be rejected for the following reasons:

1. Members of the Technical Committee are concerned about the impact on the community of adding new languages. Will it divide the community, will it form an isolated island, and will it create an additional threshold for newcomers?

two。 Some members of the Technical Committee believe that there is a lack of information, research and work on some aspects of the community. How is Go code shared across the community? How to do certification? How to do the message layer? How to produce a version? How to maintain the stability of the branch?

3. The proposed Go language team has never done any cross-project tasks other than its own project, which raises doubts about whether it can be successfully completed by many technical committees.

What conditions do you need to accept a new language?

First of all, I would like to make it clear that what I am saying does not represent the technical committee, but only my personal views, so as to facilitate communication, so that people in the whole community can express their views, whether they agree with or against my ideas.

During the discussion, I was most concerned about the first part, mainly because I felt that the migration to "Big Tent" had not yet been completed. I don't know how to make me feel that the migration has been completed, but I am sure that we need to solve the problems that we need to solve before big changes occur.

To get to the point, I increasingly like to set expectations for a lot of things, especially requests that make a difference. After listing the expectations, you can let the people concerned know in which direction they are going and find out the problems that may be faced by the change.

I'm not nearly as worried about the second question as I am about the first. It will show a strong commitment to the teams involved in discussing this change, as it involves a basic knowledge base for future use and reference for all members of the community. I thought the second part of the work might be a little out of line, but that's not the case. By studying how to share the code, how to test the code, how to output the code, how to do the authentication library, etc., we set the basics that we need to use in the future.

Anyway, what is the "basic stuff" I mentioned above? I'll talk a little bit about it in the less detailed list below:

Define how to share code and libraries for new languages

Oslo Team is responsible for maintaining libraries that are frequently used by the entire OpenStack community. These libraries include message library (oslo.messaging), i18n library (oslo.i18n), database layer library (oslo.db) and other key libraries.

These libraries themselves do not keep people in the Oslo group busy; they are designed to collect repetitive common code that previously existed in many projects in the community. This code is now removed, stabilized and released by Oslo.

I think as a community, this is inevitable. Once more and more projects use the same language, there will be a need to share code. Therefore, I think we need to better define how the code of a programming language is shared in the community, which is important, even before the programming language is accepted.

I think doing something in advance doesn't mean there's nothing to do in the future. we all know that there will be a lot of anticipated things and changes, and I think this work can involve most of the initialization work.

About the basic library of OpenStack basic services

This may seem like a fairly high goal. While it's a difficult requirement to figure out how the code is shared, I think it's a long way from the minimum requirements for OpenStack services.

OpenStack services integrated into the ecosystem require at least one of the following libraries:

Keystoneauth / keystone-client

Oslo.config

Oslo.db

Oslo.messaging

If there is no consumption when using a database or message queue abstraction library, it is likely that the layer of abstraction provided is wrong, resulting in poor API. On the other hand, the authentication layer is the part that almost all OpenStack services use, and it should be easy to use, but that doesn't mean it's simple.

By processing any of these libraries, you can perform CI (automated test system) jobs to ensure that the basic settings of the new project are correct.

Define how deliverables are distributed

The release process of OpenStack is almost completely automated, and all deliverables involved in the release process are automatically produced by the community and managed by the release team. Finally, a zip package is generated for each deliverable.

Currently, when using the Python programming language (and several other programming languages), these packages are simple because they contain only this source code. For compiled languages like Go, do we have to think about what to compress in the zip package, the compiled binaries? Should I add the source code? If you want to include binaries, should you also consider two different packages? One is binary code, the other is source code.

What about the work of maintaining a stable branch?

Stable branches are often forgotten in the community, and teams that maintain these stable branches are less appreciated. However, stable branch code runs in many OpenStack cloud environments, and they are critical for backward-compatible back-end migration fixes.

Each language has its own way of publishing libraries and managing compatibility. When adding a new programming language to the community, collaboration with other existing teams is critical.

Set up CI pipes for new languages

There is also a discussion with the infrastructure group to set up the CI (automatic Test system) pipeline.

This task may be the basis of much work. To address many of the previous tasks, it is necessary to set up CI (Automated Test system) jobs, which involve coordination with the infrastructure team. The latter is crucial. The participation of infrastructure teams is critical to adding any new language, and their feedback will play an important role in many decisions.

Reviewing some of the basic work done for the Python language is actually something that most projects need to do. I hope that teams committed to joining the new language can do something generic for future use across multiple projects.

For example, there will be general work in the following areas:

Lint checkers

Doc builders

Release Pipelines

At this point, the study on "what issues need to be considered in adding the Go language to OpenStack development" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.