<div dir="ltr">Bulat is suggesting to move with 4. He suggest to merge all actions of UpdateDnsmasqTask into one puppet task. There are three actions: syncing admin network list to heira, dhcp ranges update and cobbler sync. The problem I see with this approach is that current implementation does not suppose passing any additional data to "puppet apply". Cobbler sync seems to be a reasonable part of updating dhcp ranges config.<div class="gmail_extra"><br></div><div class="gmail_extra">Best,</div><div class="gmail_extra">Georgy</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 7:25 PM, Georgy Kibardin <span dir="ltr"><<a href="mailto:gkibardin@mirantis.com" target="_blank">gkibardin@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"><span style="font-size:13px">Hi All,</span><div style="font-size:13px"><br></div><div style="font-size:13px">Currently we can only run one instance of subj. at time. An attempt to run second one causes an exception. This behaviour at least may cause a cluster to stuck forever in "removing" state (reproduces here <a href="https://bugs.launchpad.net/fuel/+bug/1544493" target="_blank">https://bugs.launchpad.net/fuel/+bug/1544493</a>) or just produce incomprehensible "task already running" message. So we need to address the problem somehow. I see the following ways to fix it:</div><div style="font-size:13px"><br></div><div style="font-size:13px">1. Just put the cluster into "error" state which would allow user to remove it later.</div><div style="font-size:13px">  pros: simple and fixes the problem at hand (#1544493)</div><div style="font-size:13px">  cons: it would be hard to detect "come againg later" situation; quite a lame behavior: why don't you "come again later" yourself.</div><div style="font-size:13px"><br></div><div style="font-size:13px">2. Implement generic queueing in nailgun.</div><div style="font-size:13px">    pros: quite simple</div><div style="font-size:13px">    cons: it doesn't look like nailgun responsibility</div><div style="font-size:13px"><br></div><div style="font-size:13px">3. Implement generic queueing in astute.</div><div style="font-size:13px">   pros: this behaviour makes sense for astute.</div><div style="font-size:13px">   cons: the implementation would be quite complex, we need to synchronize execution between separate worker processes.</div><div style="font-size:13px"><br></div><div style="font-size:13px">4. Split the task so that each part would work with particular cluster.</div><div style="font-size:13px">   pros: we don't extend our execution model</div><div style="font-size:13px">   cons: untrivial implementation; no guarantee that we are always able to split master node tasks on per cluster basis.</div><div style="font-size:13px"><br></div><div style="font-size:13px">Best,</div><div style="font-size:13px">Georgy</div></div>
</blockquote></div><br></div></div>