Hi there,

This repo contains puppet manifests we're using in Fuel Infra to deploy our services and CI's.

Normally everything stored here could be just placed to /etc/puppet on puppet master's (in case of puppet agent use) or target node (in case of puppet apply) use. In our Infra we're using puppet master and hiera to store sensitive data like passwords and keys.

High level description for directories:

• bin - scripts, which are impossible to use from puppet manifests (for puppet master installation for instance)
• docs - dev docs describes functions of some modules and contains some examples
• hiera - configuration examples for some of services
• manifests - puppet native site.pp location
• modules - puppet native modules location

All of our flow goes through Gerrit to achieve code review purposes, so to contribute something you need to login to review.fuel-infra.org with your LP account and use standard Gerrit flow.

More details you can find here:

http://docs.openstack.org/infra/manual/developers.html

The only difference is: we're using review.fuel-infra.org instance.

1. Puppet files encoding must be ASCII
2. Host(s) configuration must be described in ::fuel_project::roles::<ROLE_NAME> (even if it is only several lines)
3. site.pp file must describe exact node with the class from previous item only.
4. Each component(describes application) module must be splited into small atomic classes, independent from other ones.

Example: Zabbix server module uses MySQL database, so Zabbix server must be installed as it's own module, database by it's own one.

class zabbix::proxy
class zabbix::database
class zabbix::proxy
class zabbix::server

1. Roles classes(located in ::fuel_project::roles::<ROLE_NAME>) must incldue ::fuel_project::common class.

2. If there's a firewall requirement it must be implemented as $firewall_enable boolean attribute, set to false by default.

3. All specific rules, must be passed as a hash called $firewall_allow_sources, set to empty hash({}) by default.

4. If specific application configuration takes place, it must be described in ::fuel_project::apps::<APP_NAME>

5. Classes within ::fuel_project::roles::<ROLE_NAME> must not pass any attributes to invoked classes, except ones could be represented as system flags, like $firewall_enable.

6. Component modules must not invoke anything within ::fuel_project module.

7. All of meaning attributes must be represented in hiera/common-example.yaml with placeholder values.

8. If there are additional package repositories required, they must be described in common-example.yaml

9. Resource declarations must contain all the requirements in require attribute.

10. Resouce chains(Resource -> Resource2 ~> Resource3) must not be used.

11. require attribute must contain references to the resources in the same module only.

12. Packages definition must have required='present' or required='package_version'.

13. Third-party modules must be installed via bin/install_modules.sh only.

14. Class attributes names must be in te following format {object_action}

    Example:

    $firewall_enable
    

15. Class and definition declarations must be covered with puppet docstrings

16. You must declare resources with ensure_* functions if duplicate declaration error is expected, except the cases when you need to fail with duplicate declaration.

17. If conditions must be with brackets.

    Example:

    if (condition) {
      ...
    }
    

18. Class attributes, hiera/common-example.yaml values must be sorted alphabetically.

19. Commit message must describe all the changes in the review.

20. Commit message must contain 'Closes-Bug: #XXXXXXX' if the patchset fixes the bug, 'Related-Bug: #XXXXXXX' if it's a part of a bug(if there's a bug exists, of course).

21. CI must be passed.

1. Manifests complete state should be achieved with the only pass.
2. You should avoid usage new applications if there is already present one covers the same needs.