属性转换机制修复和改进¶
https://bugs.launchpad.net/heat/+bug/1620859
当前转换机制存在一些错误，依赖于在数据使用前进行修改 - 因此函数无法正确转换；对 HOT 和 Cfn 函数的过度依赖；代码混乱，充斥着技巧。本规范旨在与社区讨论更好的重新实现转换机制的方法。
问题描述¶
属性转换机制 (TM) 在 Kilo 中实现，在 Newton 中重构，但仍然无法正常工作。存在一些必须强制修复的情况
TM 错误地处理函数 - 如果 TM 在转换路径的中间找到了函数，它不会解析该函数并引发错误，因为它无法获取转换路径中的下一个项目。例如，如果属性 networks 等于一个函数，并且转换路径等于 [networks, network]，那么在函数没有 get 方法的情况下，network 将无法获取。
当前的解决方法是跳过存在这种情况的转换规则。
TM 在数据使用前修改属性，这是没有意义的。首先，修改数据是不安全的。其次，如果第一步得到修复，函数在每次调用时都会被解析并返回解析后的数据，因此转换无法与它们一起工作。
TM 依赖于 HOT 和 Cfn 模板格式 - 这使得第三方模板格式插件无法在 Heat 中成为一流公民，因为它们容易在有人添加转换规则时发生故障。
TM 代码有很多混乱和棘手的地方，应该简化并使其更清晰。
提议的变更¶
在提出解决方案之前，需要注意的是，更改涉及转换机制，但不涉及转换规则以及如何在资源插件中指定它们以支持第三方资源。
接下来的更改应该修复 TM 并改进它
在获取属性期间进行转换阶段。假设函数将在转换之前被解析，属性将始终返回转换后的值。
改进当前 Property 类中无用的 name 变量，该变量将存储属性的完整名称，例如 networks.network；
在属性内部操作转换规则 - 存储 TM 对象并将其传递给属性子模式；
在转换为定义的属性类型之前调用转换 - 如果存在任何转换。
存储已调用属性的转换结果 - 这有助于避免每次调用属性时都进行转换。转换后的值将按完整名称存储，例如 networks.network。
不应在验证阶段存储结果。
此外，与其在某个字典中显式存储转换后的结果，不如使用缓存，但可能会出现问题，例如 LP#1609787 错误。
由于之前的步骤，重构并简化 TM 的庞大代码，尝试使代码更易于理解。
添加功能测试以涵盖不同的风险案例。
备选方案¶
更改当前的 TM 版本，添加对上述问题的修复。
实现¶
负责人¶
- 主要负责人
prazumovsky
里程碑¶
- 完成目标里程碑
ocata-3
工作项¶
将转换过程移动到属性获取期间。
重构 TM 以清除代码并修复不必要的依赖关系。
添加功能测试以涵盖风险案例。
依赖项¶
无
