fix: be consistent with multipele attr sets

Currently, pcs does not support multiple nvsets and system role must
deal with it. The case of multiple nvsets in node attributes was handled
differently than multiple nvsets in other cases. This fix makes dealing
with node attributes consitent with the rest.

Also in README.md is now explicitly mentioned, that (in the cases of
multiple nvsets) only the first set is used and the rest are ignored.

README.md

@@ -565,7 +565,8 @@ The items are as follows:
 * `sbd_devices` (optional) - Devices to use for exchanging SBD messages and for
   monitoring. Defaults to empty list if not set.
 * `attributes` (optional) - List of sets of Pacemaker node attributes for the
-  node. Currently, no more than one set for each node is supported.
+  node. Currently, only one set is supported, so the first set is used and the
+  rest are ignored.
 
 You may take a look at examples:
 
@@ -586,7 +587,8 @@ ha_cluster_cluster_properties:
 ```
 
 List of sets of cluster properties - Pacemaker cluster-wide configuration.
-Currently, only one set is supported.
+Currently, only one set is supported, so the first set is used and the rest are
+ignored.
 
 You may take a look at [an example](#configuring-cluster-properties).
 
@@ -640,11 +642,12 @@ role. The items are as follows:
   it will be unable to decide which agent should be used. Therefore, it is
   recommended to use full names.
 * `instance_attrs` (optional) - List of sets of the resource's instance
-  attributes. Currently, only one set is supported. The exact names and values
-  of attributes, as well as whether they are mandatory or not, depends on the
-  resource or stonith agent.
+  attributes. Currently, only one set is supported, so the first set is used and
+  the rest are ignored. The exact names and values of attributes, as well as
+  whether they are mandatory or not, depends on the resource or stonith agent.
 * `meta_attrs` (optional) - List of sets of the resource's meta attributes.
-  Currently, only one set is supported.
+  Currently, only one set is supported, so the first set is used and the rest
+  are ignored.
 * `copy_operations_from_agent` (optional) - Resource agents usually define
   default settings for resource operations (e.g. interval, timeout) optimized
   for the specific agent. If this variable is set to `true`, then those
@@ -688,7 +691,8 @@ This variable defines resource groups. The items are as follows:
   [`ha_cluster_resource_primitives`](#ha_cluster_resource_primitives). At least
   one resource must be listed.
 * `meta_attrs` (optional) - List of sets of the group's meta attributes.
-  Currently, only one set is supported.
+  Currently, only one set is supported, so the first set is used and the rest
+  are ignored.
 
 You may take a look at
 [an example](#creating-a-cluster-with-fencing-and-several-resources).
@@ -721,7 +725,8 @@ This variable defines resource clones. The items are as follows:
   generated. Warning will be emitted if this option is not supported by the
   cluster.
 * `meta_attrs` (optional) - List of sets of the clone's meta attributes.
-  Currently, only one set is supported.
+  Currently, only one set is supported, so the first set is used and the rest
+  are ignored.
 
 You may take a look at
 [an example](#creating-a-cluster-with-fencing-and-several-resources).
@@ -796,7 +801,8 @@ This variable defines resource bundles. The items are as follows:
   directories on the host's filesystem into the container. Each list of
   name-value dictionaries holds options for one directory mapping.
 * `meta_attrs` (optional) - List of sets of the bundle's meta attributes.
-  Currently, only one set is supported.
+  Currently, only one set is supported, so the first set is used and the rest
+  are ignored.
 
 Note, that the role does not install container launch technology automatically.
 However, you can install it by listing appropriate packages in

tasks/shell_pcs/pcs-node-attributes.yml

@@ -7,10 +7,8 @@
     cmd: >
       pcs -f {{ __ha_cluster_tempfile_cib_xml.path | quote }}
       -- node attribute {{ node_options.node_name | quote }}
-      {% for attr_set in node_options.attributes | d([], true) %}
-        {% for attr in attr_set.attrs | d([]) %}
-          {{ attr.name | quote }}={{ attr.value | quote }}
-        {% endfor %}
+      {% for attr in node_options.attributes[0].attrs | d([]) %}
+        {{ attr.name | quote }}={{ attr.value | quote }}
       {% endfor %}
   # We always need to create CIB to see whether it's the same as what is
   # already present in the cluster. However, we don't want to report it as a

tests/tests_cib_node_attributes.yml

@@ -43,7 +43,9 @@
           vars:
             __test_expected_lines:
               - "Node Attributes:"
-              - " {{ __test_first_node }}: attr1=val1 attr2=val2 attr3=val3"
+              # Except the first one, nvsets are ignored, so attr3=val3 is not
+              # there.
+              - " {{ __test_first_node }}: attr1=val1 attr2=val2"
           block:
             - name: Fetch node attributes configuration from the cluster
               command: