<div dir="ltr">Hi Dmitry,<div><br></div><div>The problem with merging is usually it's not clear how system performs merging.</div><div>For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k': 3}]}, and I want</div><div>{'list': [{'k': 4}]} to be merged, what system should do? Replace the list or add {'k': 4}?</div><div>Both cases should be covered.</div><div><br></div><div>Most of the users don't remember all of the keys, usually user gets the defaults, and</div><div>changes some values in place, in this case we should ask user to remove the rest</div><div>of the fields.</div><div><br></div><div>The only solution which I see is to separate the data from the graph, not to send</div><div>this information to user.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 22, 2015 at 5:18 PM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi guys,<div><br></div><div>I want to discuss the way we are working with deployment configuration that were redefined for cluster.</div><div><br></div><div>In case it was redefined by API - we are using that information instead of generated.</div><div>With one exception, we will generate new repo sources and path to manifest if we are using update (patching feature in 6.0).</div><div><br></div><div>Starting from 6.1 this configuration will be populated by tasks, which is a part of granular deployment</div><div>workflow and replacement of configuration will lead to inability to use partial graph execution API.</div><div>Ofcourse it is possible to hack around and make it work, but imo we need generic solution.</div><div><br></div><div>Next problem - if user will upload replaced information, changes on cluster attributes, or networks, wont be reflected in deployment anymore and it constantly leads to problems for deployment engineers that are using fuel.</div><div><br></div><div>What if user want to add data, and use generated of networks, attributes, etc?</div><div>- it may be required as a part of manual plugin installation (ha_fencing requires a lot of configuration to be added into astute.yaml), </div><div>- or you need to substitute networking data, e.g add specific parameters for linux bridges</div><div><br></div><div>So given all this, i think that we should not substitute all information, but only part that is present in </div><div>redefined info, and if there is additional parameters they will be simply merged into generated info</div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>