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
