apache
AMBARI-26008: Add openEuler operating system support
What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
How was this patch tested?
(Please explain how this patch was tested. Ex: unit tests, manual tests) (If this patch involves UI changes, please attach a screen-shot; otherwise, remove this)
Please review Ambari Contributing Guide before opening a pull request.
@JiaLiangC thanks for reporting and working on this. Looks there are conflicts with PR. Can you please rebase the PR.? Dn't we need to merge py3 PR's first.? and CI is failing.
@brahmareddybattula Yes, I will rebase all my PRs on the latest trunk branch.
@MacChen01 @brahmareddybattula
This PR is somewhat disruptive as it changes a lot of content. Essentially, the limitation of Ambari's support for multiple operating systems is just to ensure the use of the correct package management tool during installation. Therefore, after upgrading to Python 3, supporting different operating systems becomes easy. It only requires modifying the OS check logic to categorize operating systems based on the package manager. For instance, operating systems like Red Hat 7, 8, 9, and openEuler would return 'redhat', thus uniformly using YUM as the package manager. On the other hand, those using APT would be classified as 'ubuntu'. Our production environment has already adopted this new approach, making support for new operating systems extremely convenient, requiring changes to just one file, oscheck.py. Adding support for new operating systems in the future will become very easy. Therefore, I am still considering whether to close this PR and discuss on the mailing list whether we need to change so much code to add a new operating system or if there is a simpler way to extend support for other operating systems.
As shown in the following image: support for many operating systems has been added by merely changing this code.
@brahmareddybattula @MacChen01 @arshadmohammad If adding a new operating system means modifying 30 files, then the process of adding support for new operating systems becomes overly complicated and difficult to test. The design of Ambari itself is not the issue; what changes is merely the name of the operating system, while the package manager remains constant.
Secondly, related .c files should be removed. Many are just gilding the lily and not essential. With their removal, Ambari would only depend on Java and Python, allowing it to run on all operating systems without the need for compilation on each one.
@MacChen01 @brahmareddybattula
This PR is somewhat disruptive as it changes a lot of content. Essentially, the limitation of Ambari's support for multiple operating systems is just to ensure the use of the correct package management tool during installation. Therefore, after upgrading to Python 3, supporting different operating systems becomes easy. It only requires modifying the OS check logic to categorize operating systems based on the package manager. For instance, operating systems like Red Hat 7, 8, 9, and openEuler would return 'redhat', thus uniformly using YUM as the package manager. On the other hand, those using APT would be classified as 'ubuntu'. Our production environment has already adopted this new approach, making support for new operating systems extremely convenient, requiring changes to just one file, oscheck.py. Adding support for new operating systems in the future will become very easy. Therefore, I am still considering whether to close this PR and discuss on the mailing list whether we need to change so much code to add a new operating system or if there is a simpler way to extend support for other operating systems.
As shown in the following image: support for many operating systems has been added by merely changing this code.
@JiaLiangC This is a good idea, but this approach is not very standardized. Do you think we may need to consider restructuring the structure of ambari? Welcome to open the discussion.
@MacChen01 @brahmareddybattula
This PR is somewhat disruptive as it changes a lot of content. Essentially, the limitation of Ambari's support for multiple operating systems is just to ensure the use of the correct package management tool during installation. Therefore, after upgrading to Python 3, supporting different operating systems becomes easy. It only requires modifying the OS check logic to categorize operating systems based on the package manager. For instance, operating systems like Red Hat 7, 8, 9, and openEuler would return 'redhat', thus uniformly using YUM as the package manager. On the other hand, those using APT would be classified as 'ubuntu'. Our production environment has already adopted this new approach, making support for new operating systems extremely convenient, requiring changes to just one file, oscheck.py. Adding support for new operating systems in the future will become very easy. Therefore, I am still considering whether to close this PR and discuss on the mailing list whether we need to change so much code to add a new operating system or if there is a simpler way to extend support for other operating systems.
+1 for this idea. Many operating systems now use YUM as the package manager. If these OS can be grouped into one category, it will be much simpler to add similar operating systems in the future.