<div dir="ltr"><div><div><div>Hi,<br><br></div>well, we have only one DHCP server that serves multiple clusters. Actions with those multiple clusters may affect DHCP server configuration. So queueing tasks that change DHCP server configuration seems like a reasonable way to fix the problem. So options 2 and 3 are much better than 1 or 4.<br><br></div>Regards,<br></div>Alex<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 10:59 AM, 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"><div>Continuing speaking to myself :)</div><div><br></div>Option 4 implies that we generate puppet manifest with a set of admin networks instead of writing it into hiera. So, we get a two step task which, first, generates manifest with unique name and, second, calls puppet to apply it.<div>However, theres still a problem with this approach. When we almost simultaneously delete environments A and B (and A goes a bit earlier) astute acknowledges two UpdateDnsmasqTask tasks for execution, however, it cannot guarantee that puppet for UpdateDnsmasqTask for env A will be executed earlier than for env B. This would lead to incorrect list of admin networks by the end of environment deletion.</div><div><br></div><div>So the option 4 just doesn't work.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 11:41 AM, 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">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><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></div></div>
</blockquote></div><br></div>
</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" 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></blockquote></div><br></div>