<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>