On 04/01/2016 10:41 AM, Oleg Gelbukh wrote: > Andrew, > > This is an excellent idea. It is apparently more efficient and > error-proof to make the split not by the resulted data but at the time > it is actually generated. We will play with this idea a little bit, and > will come up with design proposal shortly. > > Meanwhile, please be informed that we already started testing the > solution based on the node-level data exposed via ConfigDB API extension > for Nailgun [1] [2]. I will keep you updated on our progress in that area.
I strongly believe that nodes must only consume data, not provide one. And the data must be collected from its sources, which is Nailgun API extensions, like Andrew described. > > [1] Specification for Nailgun API for serialized facts > <https://review.openstack.org/284109> > [2] Spec for upload of deployment configuration to ConfigDB API > <https://review.openstack.org/286012> > > -- > Best regards, > Oleg Gelbukh > > On Thu, Mar 31, 2016 at 11:19 PM, Andrew Woodward <[email protected] > <mailto:[email protected]>> wrote: > > 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 > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > <http://[email protected]?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
