Hi, General info Detailed documentation is available in the latest spec [1] (see [2] for HTML format). You can also check blue-print [3] and etherpad how-to [4] for more info.
Fuel-library granularization status As you may know, we're using granular task based deployment in master branch already. Currently we have a set of separate manifests that are applied by puppet as separate tasks, they are stored here [5]. According to our implementation plan (step #2, see spec for details) we moved node roles (controller, compute, cinder, ceph-osd, mongo, zabbix-server) into separate tasks. So every role is deployed by its own separate puppet manifest applied as Fuel task. We're also going to remove the following files shortly as we no longer use/need them: deployment/puppet/osnailyfacter/examples/site.pp deployment/puppet/osnailyfacter/manifests/cluster_ha.pp deployment/puppet/osnailyfacter/manifests/cluster_simple.pp deployment/puppet/osnailyfacter/modular/legacy.pp So here are few examples, just to illustrate current deployment process: 1) Controller (primary and non-primary) role: puppet apply /etc/puppet/modules/osnailyfacter/modular/hiera.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/globals.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/logging.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/netconfig.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/firewall.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/hosts.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/tools.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/controller.pp 2) Compute role: puppet apply /etc/puppet/modules/osnailyfacter/modular/hiera.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/globals.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/logging.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/netconfig.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/firewall.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/hosts.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/tools.pp puppet apply /etc/puppet/modules/osnailyfacter/modular/compute.pp Hiera Also we're switching from parseyaml() function and global $::fuel_settings hash to Hiera. All the configuration data should be pulled into manifests via hiera() only. Hiera is configured by the first two tasks: /etc/puppet/modules/osnailyfacter/modular/hiera.pp - configures Hiera /etc/puppet/modules/osnailyfacter/modular/globals.pp - creates /etc/hiera/globals.yaml file with node-specific calculated data that should help to avoid code duplication in manifests For example: globals.yaml contains *internal_address* for the node and you can pull it via hiera: root@node-1:~# hiera internal_address 192.168.0.3 Without globals.yaml you would have to search for internal_address in nodes hash in astute.yaml. You can see current modular manifests for more examples. CI updates We also have some changes in fuel-library CI related to granular deployment. Since our deployment process depends on tasks, which are shipped with fuel-library repo, we've added new CI test job [6] that runs basic schema validation and makes sure we have acyclic tasks graph. [1] https://review.openstack.org/147591 [2] http://docs-draft.openstack.org/91/147591/13/check/gate-fuel-specs-docs/e58793b//doc/build/html/specs/6.1/fuel-library-modularization.html [3] https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization [4] https://etherpad.openstack.org/p/fuel-library-modularization [5] https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/osnailyfacter/modular [6] https://fuel-jenkins.mirantis.com/job/fuellib_tasks_graph_check -- Regards, Aleksandr Didenko
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev