Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-20 Thread Aleksandr Didenko
Hi folks, it turned out that one change has to be made in your plugins though. If you're reusing 'netconfig' task for your custom roles, you need to remove 'configure_default_route' task from your roles (if you have it) and add 'hiera_default_route'. This is needed for proper default gateway

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-07 Thread Aleksandr Didenko
Hi, you don't need to change anything in your plugin, we still have the same netconfig.pp task on all nodes even after bugfix. Regards, Alex On Tue, Jun 7, 2016 at 8:21 AM, Igor Zinovik wrote: > Hello, > > Aleksandr, one simple question: do I as a plugin developer for

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-07 Thread Igor Zinovik
Hello, Aleksandr, one simple question: do I as a plugin developer for upcoming Fuel 9.0 have to worry about these network-related changes or not? HCF is approaching, but patch that you mentioned (342307 ) is still not merged. Do I need to spend time on

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-06 Thread Aleksandr Didenko
Hi, a bit different patch is on review now [0]. Instead of silently replacing default gateway on the fly in netconfig.pp task it's putting new default gateway into Hiera. Thus we'll have idempotency for subsequent netconfig.pp runs even on Mongo roles. Also we'll have consistent network

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-01 Thread Aleksandr Didenko
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).

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Simon Pasquier
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,

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Adam Heczko
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 wrote: > Hey Adam, > > in Fuel we have the following option

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Aleksandr Didenko
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

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Adam Heczko
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)

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Aleksandr Didenko
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.

[openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-19 Thread Aleksandr Didenko
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