大家都在吐槽openstack太复杂，为此我很想反驳，但它确实很复杂......我们四人参与升级的任务已经执行了一个月（我两周前加入），慎重起见，我们已经经历了自己搭建的M版升级、模拟线上公有云的升级、升级步骤脚本化，接下来还要进行研发环境升级，最后升级公有云，预计耗时一个半月。如果还要模拟回滚、验证，估计时间还要double......陆陆续续跟着老司机们加班，已是强弩之末，深怕过程出错，丢了用户数据，坏了公司名声。我相信咱们历经此番，未来可以为客户节约很多时间和人力的投入
稍稍解释一下躺过的坑，大家可以思考一下DevOps的如何优化
慎重使用rm操作
标题够醒目吧，跟着心里默念三遍，嗯，你以为你慎重了吗？你以为你慎重了就不会让华为赔了5个亿吗？事实上这是一句屁话，只要rm操作没被禁用，你就会犯错。比如我在测试升级trove实例的时候需要把trove源码拷贝进去，压缩包叫trove.rar，经过长时间的操作，我也不知道home下那个trove目录是不是我解压出来的，于是我rm了......悲剧的是这个trove目录里面有几个配置文件，丢失了它就没有办法知道数据库的密码，也会丢失trove实例的ID，实例也就无法和控制节点通信......我想表示的是我已经很慎重了。有些公司的做法是把bash里的rm重定向到mv操作......
执行yum update后依赖包没升级
升级包有两种方式，一种是yum remove再install，但我们不知道remove会删除什么东西，所以另一种做法是yum update，但是update有时是不会升级依赖包的，如果依赖包变化较大，出了问题可是要排查很久的
trove实例需要手动升级......
这个组件在M版不够成熟，在N版增加了upgrade机制，可以通过重建实例的方式升级到最新版本，然并暖......
当时预研这个trove实例的时候，发现一个哥们提交了一个patch，他的设计思想是通过api通知trove实例从swift存储里面下载最新的guest-agent，kill掉旧进程，然后在virtualenv里面启动服务，从2014年2月提交patch后陆陆续续根据reviewer的建议持续修复，直到2014年11月被PTL无理由否决。。。求心理阴影面积，不过话说回来，我觉得还是upgrade机制更好
trove控制节点升级后，对应的datastore需要更新image-id
在恢复备份时间点的时候想选择新的datastore创建实例，但被系统拒绝，可是旧的datastore镜像还是M版，恢复出来的实例无法使用
大量的配置文件需要修改、对比、review
你们懂的，错了一条配置信息够你排查一上午了
一些组件修改了规则，但其他组件没及时跟上变化
比如鉴权模块keystone在O版删掉domain表，咱们M版是通过domain找到相关信息，升级上来后就懵逼了，trove模块直接鉴权失败
glance上传镜像的时候参数错误，导致无法挂载云盘
幸好团队中有专家，轻松化解，we have a team
released note列出了每个版本升级后必须执行的命令
如果你没review到这些信息，系统不会按照你想的那样运行
流程依赖
比如停止服务的时候需要注意先后顺序
清理无效token
测试环境里面的token表居然有15G之多。。。数据库备份要哭
网友评论