Question

转发层（composition layer）模块实际上是对第二部分所介绍的模块的调用。 官方社区曾经有一个转发层模块称为 puppet-openstack，在 Juno 版本时被标记为弃用。 为什么社区不推荐转发层模块呢？因为这玩意和自家业务结合得非常紧密。比如，Fuel 有自己的转发层模块 cluster ,ctask 有自己的转发层 sunfire。

那么关于它的最佳实践是什么？

2016 年 1 月份，我们刚完成了对转发层 sunfire 的重构，甩掉了许多的历史包袱。关于转发层，我们有以下几点原则需要严格遵守:

逻辑清晰

概括来讲就是在转发层中，不允许出现对 resource 的直接调用，所有转发层的类抑或定义，只能直接调用基础模块，Openstack 模块中的类或定义。

打个不是非常恰当的比方:

class  sunfire::api(){
  # 这块代码就应该被移除，使用 include ::nova::client 来替换
  package {'python-novaclient':
    ensure => present,
  }
  include ::nova
  include ::nova::api
}

数据和逻辑分离

我们在早期使用 Puppet 时并没有使用到 Hiera，因此转发层承载了大量参数的默认值设置。这样做的好处是，我们需要使用到的参数都赋有一个合理默认值，但是坏处是数据和逻辑没有完全分离开。 比如说，我想查询一下目前线上集群$keystone_user_password 的值，可能是在转发层的代码中，也可能是记录在 hieradata 中。另外一个不好的地方就是代码会变得非常冗余。

打个比方:

  class sunfire::api(
    $nova_db_password = 'nova',     #先定义一个参数
  ){
   class {'nova::db::mysql':
     db_password => $nova_db_password, #把该参数值传给真正需要赋值的参数
   }
  }

完全分离的写法:

  class  sunfire::api(){
   include ::nova::db::mysql
  }

角色松耦合

我们习惯把转发层中的每个 class 称之为角色，这样比较形象，例如:

• sunfire::api 表示 API 节点
• sunfire::mq 表示 MQ 节点
• sunfire::loadbalancer::l7 表示 7 层负载均衡

那么 API 角色中，又包含了 nova/cinder/neutron/glance/... api,keystone 等大量的服务。同时我们又要满足某些情况下，某些服务不启用的需求。例如，某用户表示，他们不需要使用 neutron server 而启用 nova-network。 有两种方式来满足这种要求：

• 在 sunfire::api 添加开关:

  class sunfire::api(
    $enable_neutron = true,
  ){
    if $enable_neutron {
      include ::neutron::server
    }
  }
  

• 在 main manifests 文件中声明：

  'xxx api node' {
  include ::neutron::server
  }