Open Stack

One of the problems we've faced with trying to plug-in ConfigDB is trying
to separate the cluster attributes from the node attributes in the
serialized output (ie astute.yaml)

I started talking with Alex S about how we could separate them after
astute.yaml is prepared trying to ensure which was which we came back
uncertain that the results would be accurate.

So I figured I'd go back to the source and see if there was a way to know
which keys belonged where. It turns out that we could solve the problem in
a simpler and more precise way than cutting them back apart later.

Looking over the deployment_serializers.py [1] the serialized data follows
a simple work flow

iterate over every node in cluster
  if node is customized:
    serialized_data = node.replaced_deployment_data
  else:
    serialized_data = dict_merge(
      serialize_node(node),
      get_common_attrs(cluster))

Taking this into mind, we can simply construct an extension to expose these
as an APIs so that we can consume them as a task in the deployment graph.

Cluster:
We can simply expose
DeploymentMultinodeSerializer().get_common_attrs(cluster)

This would then be plumbed to the cluster level in ConfigDB

Node:
if a Node has customized data, then we can return that at the node level,
this continues to work at the same as native since it most likely has
Cluster merged into it.

otherwise we can return the serialized node with whichever of the first
'role' the node has

We would expose DeploymentMultinodeSerializer().serialize_node(node,
objects.Node.all_roles(node)[0])

for our usage, we don't need to worry about the normal node role
combination as the data only influences 'role' and 'fail_if_error'
attributes, both are not consumed in the library.

https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L93-L121
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/8b3117df/attachment.html>