付老师,你好:
非常感谢你的建议,检测出哪些二进制不能兼容的情况下,有一个”中间层”,实现在OS 升级的情况下,对已有软件的兼容,是一个非常有创造力的想法,实际目前受开源组件版本升级的影响,惯用的做法是在某个OS版本编译出来的业务软件就在对应的版本OS上安装使用,避免版本不配套带来的兼容性问题。
为了支撑更好的做搬迁,减少操作系统升级对业务软件带来的影响,目前社区也在探索一些方法,比如说多版本引入、容器化,这些都可以作为 迁移主线的一个补充,前期SIG组也做过一些分享及探讨,目前这方面正在进行中。
对于操作系统的组件,有中间件、运行库、加速库等分层,这个“中间层“是否存在、在哪层定义比较合适,每层实现有哪些约束及挑战,运行框架如何保障加载配套的版本,欢迎下次兼容性SIG会议上在“中间层”的方向上做一些探讨。
谢谢! openEuler 杜开田
发件人: fugz1@chinatelecom.cn fugz1@chinatelecom.cn 发送时间: 2023年2月24日 10:48 收件人: oecompatibility oecompatibility@openeuler.org 主题: [Oecompatibility] openeuler社区兼容性问题讨论
大家好:
我是天翼云基础架构,系统软件的研发同事。我们使用openeuler社区版本20.03 sp1版本自研了ctyunos2系统。 当前也在做使用x2工具做搬迁适配工作,以及发布基于22。03 sp1的ctyunos3版本. 这多方面的工作交叉过程中,我们思考了一个问题,就是怎样能基于x2工具,开发实现一个类似20.03->-22.03的无感知升级。 这里的痛点是我资源池现网的环境上,已经大批量使用2003的版本,所有的业务软件都是基于此版本编译发布。 对于电信这种大体量的业务适配和替换周期会很长(2/3年),所以希望能把现网系统直接替换成22.03后,原来的2003上的业务二进制保留。 无感知正常运行,在中间做一层隔离层,其实就是当前x2工具可以检测出哪些二进制不能兼容保留的情况下,针对这些不兼容软件,做一个框架,实现能保留下来。 给客户多一个选择,是保留还是适配新的系统版本。完善,扩展x2的上游能力。
________________________________ 付广哲 天翼云科技有限公司 基础架构事业部 电话:15311615356 地址:北京市海淀区 庚坊大厦5层