<div dir="ltr">Bogdan,<div><br></div><div>I mostly agree with you on this. The only data that might originate from a node is discovery-related parameters, like CPU/disks/NICs architecture and such.</div><div><br></div><div>However, at the moment the deployment data is partially generated at every node (i.e. globals.yaml, override/plugins/* and some other files) and is not exposed in any way externally. But since this data is required to integrate with 3rd-party configuration management tools, we create an interim solution to make them available 'as is'.</div><div><br></div><div>This situation should change in the next few months, and then nodes shall be moved to purely consumer role in the deployment data pipeline.</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 1:37 PM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/01/2016 10:41 AM, Oleg Gelbukh wrote:<br>
> Andrew,<br>
><br>
> This is an excellent idea. It is apparently more efficient and<br>
> error-proof to make the split not by the resulted data but at the time<br>
> it is actually generated. We will play with this idea a little bit, and<br>
> will come up with design proposal shortly.<br>
><br>
> Meanwhile, please be informed that we already started testing the<br>
> solution based on the node-level data exposed via ConfigDB API extension<br>
> for Nailgun [1] [2]. I will keep you updated on our progress in that area.<br>
<br>
</span>I strongly believe that nodes must only consume data, not provide one.<br>
And the data must be collected from its sources, which is Nailgun API<br>
extensions, like Andrew described.<br>
<span class=""><br>
><br>
> [1] Specification for Nailgun API for serialized facts<br>
</span>> <<a href="https://review.openstack.org/284109" rel="noreferrer" target="_blank">https://review.openstack.org/284109</a>><br>
<span class="">> [2] Spec for upload of deployment configuration to ConfigDB API<br>
</span>> <<a href="https://review.openstack.org/286012" rel="noreferrer" target="_blank">https://review.openstack.org/286012</a>><br>
<span class="">><br>
> --<br>
> Best regards,<br>
> Oleg Gelbukh<br>
><br>
> On Thu, Mar 31, 2016 at 11:19 PM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>>> wrote:<br>
><br>
> One of the problems we've faced with trying to plug-in ConfigDB is<br>
> trying to separate the cluster attributes from the node attributes<br>
> in the serialized output (ie astute.yaml)<br>
><br>
> I started talking with Alex S about how we could separate them after<br>
> astute.yaml is prepared trying to ensure which was which we came<br>
> back uncertain that the results would be accurate.<br>
><br>
> So I figured I'd go back to the source and see if there was a way to<br>
> know which keys belonged where. It turns out that we could solve the<br>
> problem in a simpler and more precise way than cutting them back<br>
> apart later.<br>
><br>
> Looking over the deployment_serializers.py [1] the serialized data<br>
> follows a simple work flow<br>
><br>
> iterate over every node in cluster<br>
> if node is customized:<br>
> serialized_data = node.replaced_deployment_data<br>
> else:<br>
> serialized_data = dict_merge(<br>
> serialize_node(node),<br>
> get_common_attrs(cluster))<br>
><br>
> Taking this into mind, we can simply construct an extension to<br>
> expose these as an APIs so that we can consume them as a task in the<br>
> deployment graph.<br>
><br>
> Cluster:<br>
> We can simply expose<br>
> DeploymentMultinodeSerializer().get_common_attrs(cluster)<br>
><br>
> This would then be plumbed to the cluster level in ConfigDB<br>
><br>
> Node:<br>
> if a Node has customized data, then we can return that at the node<br>
> level, this continues to work at the same as native since it most<br>
> likely has Cluster merged into it.<br>
><br>
> otherwise we can return the serialized node with whichever of the<br>
> first 'role' the node has<br>
><br>
> We would expose DeploymentMultinodeSerializer().serialize_node(node,<br>
> objects.Node.all_roles(node)[0])<br>
><br>
> for our usage, we don't need to worry about the normal node role<br>
> combination as the data only influences 'role' and 'fail_if_error'<br>
> attributes, both are not consumed in the library.<br>
><br>
> <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L93-L121" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L93-L121</a><br>
> --<br>
><br>
> --<br>
><br>
> Andrew Woodward<br>
><br>
> Mirantis<br>
><br>
> Fuel Community Ambassador<br>
><br>
> Ceph Community<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</div></div>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<span class="im HOEnZb">><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>