Open Stack

Continuing speaking to myself :)

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

So the option 4 just doesn't work.

On Wed, Jul 6, 2016 at 11:41 AM, Georgy Kibardin <gkibardin at mirantis.com>
wrote:

> 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/20160707/04060ee4/attachment.html>