From 88631993896dab6cec944d310da46c8e74edb3ae Mon Sep 17 00:00:00 2001 From: Ukov Dmitry Date: Fri, 9 Sep 2016 11:15:14 +0300 Subject: [PATCH] Extending Advanced Config feature Change-Id: I792cf4a53a57c73955731e20ef4065a7b5f72678 Blueprint: puppet-resource-override --- specs/9.0/puppet-resource-override.rst | 286 +++++++++++++++++++++++++ 1 file changed, 286 insertions(+) create mode 100644 specs/9.0/puppet-resource-override.rst diff --git a/specs/9.0/puppet-resource-override.rst b/specs/9.0/puppet-resource-override.rst new file mode 100644 index 00000000..819bb3e7 --- /dev/null +++ b/specs/9.0/puppet-resource-override.rst @@ -0,0 +1,286 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +=========================================================== +Allow a user to override the Puppet resources through Hiera +=========================================================== + +https://blueprints.launchpad.net/fuel/+spec/puppet-resource-override + +Currently, a user can provide the YAML-formatted data to override the +OpenStack configuration resources. This is implemented by using a specific +Puppet resource which allows overriding parameters only for the OpenStack +configuration resources in the catalog. This approach should be extended to +support all the Puppet resources what gives an opportunity to control a +deployment using Hiera. Implementing this enhancement allows us to enable +the Infrastructure as Code concept for a user. + +------------------- +Problem description +------------------- + +The Fuel OpenStack configuration feature introduces a way to update the +OpenStack configuration files. A user can upload the YAML-formatted file +using the Fuel CLI. The format of this file is as follows: + +.. code-block:: yaml + + configuration: + : + /: + : + +This format being transparently transformed into the Puppet resource is +responsible for the OpenStack configuration. + +The common Lifecycle Management and Infrastructure as Code approaches imply +that a user can configure any entity within environment (configuration file, +package version, and so on). The current solution is limited by the OpenStack +configuration file only. It leads to the significant obstacles in an +environment management after it has been deployed. + +---------------- +Proposed changes +---------------- + +To solve the problem above, we can extend Fuel to support configuration of any +entity within a deployed environment. This provides an opportunity to manage +an environment without introducing the sophisticated deployment procedures +such as creating plugins or custom graphs. + +To implement this solution, we need to change the configuration data format +to support any Puppet resource defined by ``fuel-library``. The new data format +should be recognized by the ``override_resources`` Puppet type and should +allow a user to create a new resource of a given type. The new data structure +should have the following format: + +.. code-block:: yaml + + configuration: + : + data: + : + : value1 + : value2 + ... + create_res: + +This structure should be transformed into parameters for the +``override_resources`` type. + +The ``override_resources`` Puppet type has following logic: + +#. It searches for all the resources in the Puppet catalog whose type + equals ````. + +#. Among all the resources found in the step 1, it selects resources with + title equals ````. + +#. If the result from the step 2 is not empty (if the resource is found), + it updates the resource parameters with the values from + ````. + +#. If the result from the step 2 is empty, ``create_res`` defines the + following behavior: + + a. If ``create_res = True``, the new ```` resource + with the title ```` and parameters + ``...`` is created. + b. If ``create_res = False``, the resource is not be created. + +The resource generator raises an error if the resource defined in data +structure is not found within ``modulepath``. + +Such data structures can be created using standard Nailgun API which +was introduced for the *Advanced Configurations* feature or through the +Nailgun extension which modify deployment data prior to sending them to +a particular node. + +For example, the following construction: + +.. code-block:: yaml + + configuration: + package: + data: + fontconfig-config: + ensure: latest + mc: + ensure: absent + create_res: true + +will be transformed into the following Puppet resource definition: + +.. code-block:: puppet + + override_resources {'package': + data => { 'fontconfig-config' => + {'ensure' => 'latest'}, + 'mc' => + {'ensure' => 'latest'} + }, + create_res => true, + } + +The new approach allows overriding any Puppet resource in a catalog or add +any resource in ``modulepath`` to the catalog. + +Web UI +====== + +None + +Nailgun +======= + +None + +Data model +---------- + +None + +REST API +-------- + +None + +Orchestration +============= + +None + +RPC Protocol +------------ + +None + +Fuel Client +=========== + +None + +Plugins +======= + +None + +Fuel Library +============ + +The static ``override_recources`` definition in the Fuel library +will be replaced with the dynamic one based on the data in Hiera. +The ``override_resources`` type should be created using the +``create_resources`` function. + +------------ +Alternatives +------------ + +None + +-------------- +Upgrade impact +-------------- + +All data uploaded to an environment by using the old configuration format +should be converted to the new format. + +--------------- +Security impact +--------------- + +None + +-------------------- +Notifications impact +-------------------- + +None + +--------------- +End user impact +--------------- + +None + +------------------ +Performance impact +------------------ + +None + +----------------- +Deployment impact +----------------- + +None + +---------------- +Developer impact +---------------- + +None + +--------------------- +Infrastructure impact +--------------------- + +None + +-------------------- +Documentation impact +-------------------- + +Documentation should be updated with the new configuration format examples +and description of new possible options from an end-user perspective. + +-------------- +Implementation +-------------- + +Assignee(s) +=========== + +Primary assignee: + dukov + +Mandatory design review: + vkuklin + +Work Items +========== + +The development may be split into two stages: + +* Implement a new configuration format processing in the OpenStack-related + puppet tasks. +* Implement a new configuration task for all the Puppet tasks in the + deployment graph. + +Dependencies +============ + +None + +------------ +Testing, QA +------------ + +Tests for the Fuel OpenStack configuration feature should be updated with +the new configuration format. + +Acceptance criteria +=================== + +This change should provide an ability for a user to configure any entity +within a deployed environment. + +---------- +References +---------- + +None \ No newline at end of file