Ann
自定义负载均衡支持 use-regex。生成的url包含正则时会报错
`GetAttributeFlags`函数对新建对象无效，可能需要使用`GetInitialStateAttributeFlags`函数。 排查所有`GetAttributeFlags` 函数
可以编辑其他人名下的lnk，需避免
类似sidecar设计方式 #79 ， 提供只读name，version，yaml属性 一种可能的使用方式： 新增一个KubeAppStore类，Controller引用该类。如果是引用模式，要解决表单必填项的问题，自动计算某些必填项的值，或者必填项只读 KubeAppStore可以有一个icon属性，用来提供图片，一个disclaimer属性，显示一些免责声明，或者其他一些诸如使用手册，参考链接，Dockerfile源码地址等等，提供一个页面，抓取这些信息并展示出来
定时扩缩容
HPA适用于面向最终用户的一般互联网应用，负载增加降低都比较平缓。 考虑如下情况，电视客户端有某种定时任务行为，在半夜3点低峰期（已应用HPA缩容至最低实例数量），突然流量翻了好几倍，持续大约1分钟，HPA根本来不及扩容。 这种做法不太合理，但是也有迁就的方案。考虑添加cmdb对象管理定时扩容，通过cmdb定时任务， - 每5分钟检查未来7分钟（大于5分钟，防止漏掉2次检查之间的）有无扩容任务，如有，修改HPA对象（HPA对象需记录原min值）min值，实现扩容 - 每5分钟检查未来7分钟有无缩容任务，如有，恢复HPA原min值 问题： 如何更新HPA? 当在cmdb有自定义HPA对象时，可以通过cmdb触发器触发kubernetes.php脚本去更新k8s对象，但是使用默认HPA策略（不在cmdb中自定义hpa策略）时，需要考虑如何触发k8s更新
checktowrite, checktodelete等函数中将需要更新的操作发送到mq，另一个程序负责去做更新。好处是可以替换action_shell_exec，不用去维护大量的触发器和动作
update_functionalci_contacts动作ID参数传递的是applicationsolution的id，只会更新APP现有上游资源的联系人，已删除关联的不会被更新，需要考虑其他方式，或者不做处理（影响不大） ``` SCRIPT_NAME=update_functionalci_contacts.php ID=$this->applicationsolution_id$ ```
FunctionalCI对Person的impact direction只有down，意味着从人员看依赖图看不到FunctionalCI，但是FunctionalCI看影响图却可以看到Person，可以用这个特性做报警订阅： 1. 允许Person编辑自己依赖的配置项，并将tab名称改为 “报警订阅”，并添加提示 “当你想接收其他人名下的APP或服务器的报警时，可以在这里添加” 2. 禁止普通用户编辑自己负责的APP，实现APP交接工单，工单应交出方发起，并且可以设置是否删除自己（是转移APP还是增加APP负责人）
1. 服务器链接到app，app链接到报警规则，更新cmdbApi中alertrule相关代码，查询ip报警阈值时要查到app链接的规则去，这样一个app新增机器时就不用单独加报警阈值了。 2. 一个FunctionalCI可以链接到多个同类型报警规则，不合理，比如负载报警阈值为50和100。需要在DoCheckToWrite中做检查 3. 考虑改成lnkAlertRuleToApplicationSolution，只允许链接APP
1. APP交接 交出方提单，可选新增负责人或者完全交出 2. 机器申请 表单里仅能指定一个APP，可勾选多台机器（限制只能从stock状态机器中勾选） 3. 机器归还 允许研发编辑APP添加机器依赖项（被添加的机器需归属在当前用户名下），因此当APP交接时，可能存在一个机器影响多个不同负责人的APP的情况，机器下线流程需要处理这种情况。 理想情况下机器不允许链接至多个不同负责人的APP，这样机器归还时就不用多人确认。 方案1：如果该服务器仅链接至一个APP，则不允直接许删除该链接，需要通过工单，否则允许直接在APP里删除服务器。通过工单系统归还服务器时，首先删除该人员名下所有APP与该服务器的链接，然后检查服务器是否仍有APP链接，如有，则保持状态不变（有其他负责人），如没有，则服务器变为库存状态，并修改主机名为op-stock，如有可能，执行重装并重新初始化。