Hi,

YAQL expressions support for task dependencies has been added to Nailgun
[0]. So now it's possible to fix network configuration idempotency issue
without introducing new 'netconfig' task [1]. There will be no problems
with loops in task graph in such case (tested on multiroles, worked fine).
When we deprecate role-based deployment (even emulated), then we'll be able
to remove all those additional conditions from manifests and remove
'configure_default_route' task completely. Please feel free to review and
comment the patch [1].

Regards,
Alex

[0] https://review.openstack.org/#/c/320861/
[1] https://review.openstack.org/#/c/322872/

On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier <spasqu...@mirantis.com>
wrote:

> Hi Adam,
> Maybe you want to look into network templates [1]? Although the
> documentation is a bit sparse, it allows you to define flexible network
> mappings.
> BR,
> Simon
> [1]
> https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates
>
> On Wed, May 25, 2016 at 10:26 AM, Adam Heczko <ahec...@mirantis.com>
> wrote:
>
>> Thanks Alex, will experiment with it once again although AFAIR it doesn't
>> solve thing I'd like to do.
>> I'll come later to you in case of any questions.
>>
>>
>> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
>> adide...@mirantis.com> wrote:
>>
>>> Hey Adam,
>>>
>>> in Fuel we have the following option (checkbox) on Network Setting tab:
>>>
>>> Assign public network to all nodes
>>> When disabled, public network will be assigned to controllers only
>>>
>>> So if you uncheck it (by default it's unchecked) then public network and
>>> 'br-ex' will exist on controllers only. Other nodes won't even have
>>> "Public" network on node interface configuration UI.
>>>
>>> Regards,
>>> Alex
>>>
>>> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko <ahec...@mirantis.com>
>>> wrote:
>>>
>>>> Hello Alex,
>>>> I have a question about the proposed changes.
>>>> Is it possible to introduce new vlan and associated bridge only for
>>>> controllers?
>>>> I think about DMZ use case and possibility to expose public IPs/VIP and
>>>> API endpoints on controllers on a completely separate L2 network (segment
>>>> vlan/bridge) not present on any other nodes than controllers.
>>>> Thanks.
>>>>
>>>> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <
>>>> adide...@mirantis.com> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> we had to revert those changes [0] since it's impossible to propery
>>>>> handle two different netconfig tasks for multi-role nodes. So everything
>>>>> stays as it was before - we have single task 'netconfig' to configure
>>>>> network for all roles and you don't need to change anything in your
>>>>> plugins. Sorry for inconvenience.
>>>>>
>>>>> Our current plan for fixing network idempotency is to keep one task
>>>>> but change 'cross-depends' parameter to yaql_exp. This will allow us to 
>>>>> use
>>>>> single 'netconfig' task for all roles but at the same time we'll be able 
>>>>> to
>>>>> properly order it: netconfig on non-controllers will be executed only
>>>>> aftetr 'virtual_ips' task.
>>>>>
>>>>> Regards,
>>>>> Alex
>>>>>
>>>>> [0] https://review.openstack.org/#/c/320530/
>>>>>
>>>>>
>>>>> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <
>>>>> adide...@mirantis.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>>>>>>
>>>>>> - netconfig-controller - executed on controllers only
>>>>>> - netconfig - executed on all other nodes
>>>>>>
>>>>>> puppet manifest is the same, but tasks are different. We had to do
>>>>>> this [0] in order to fix network idempotency issues [1].
>>>>>>
>>>>>> So if you have 'netconfig' requirements in your plugin's tasks,
>>>>>> please make sure to add 'netconfig-controller' as well, to work properly 
>>>>>> on
>>>>>> controllers.
>>>>>>
>>>>>> Regards,
>>>>>> Alex
>>>>>>
>>>>>> [0] https://bugs.launchpad.net/fuel/+bug/1541309
>>>>>> [1]
>>>>>> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Adam Heczko
>>>> Security Engineer @ Mirantis Inc.
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Adam Heczko
>> Security Engineer @ Mirantis Inc.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to