Open Stack

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.

Best,
Georgy

On Thu, Jun 16, 2016 at 7:25 PM, Georgy Kibardin <gkibardin at mirantis.com>
wrote:

> Hi All,
>
> 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
> https://bugs.launchpad.net/fuel/+bug/1544493) or just produce
> incomprehensible "task already running" message. So we need to address the
> problem somehow. I see the following ways to fix it:
>
> 1. Just put the cluster into "error" state which would allow user to
> remove it later.
>   pros: simple and fixes the problem at hand (#1544493)
>   cons: it would be hard to detect "come againg later" situation; quite a
> lame behavior: why don't you "come again later" yourself.
>
> 2. Implement generic queueing in nailgun.
>     pros: quite simple
>     cons: it doesn't look like nailgun responsibility
>
> 3. Implement generic queueing in astute.
>    pros: this behaviour makes sense for astute.
>    cons: the implementation would be quite complex, we need to synchronize
> execution between separate worker processes.
>
> 4. Split the task so that each part would work with particular cluster.
>    pros: we don't extend our execution model
>    cons: untrivial implementation; no guarantee that we are always able to
> split master node tasks on per cluster basis.
>
> Best,
> Georgy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160706/75a19eae/attachment.html>