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 configuration for cases when public network is assigned on controllers only. Here's an example of patch for plugin [0] and bug about it [1]
Regards, Alex [0] https://review.openstack.org/#/c/328225/2/deployment_tasks.yaml [1] https://bugs.launchpad.net/fuel-plugins/+bug/1591117 On Tue, Jun 7, 2016 at 11:46 AM, Aleksandr Didenko <adide...@mirantis.com> wrote: > 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 <izino...@mirantis.com> > wrote: > >> 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 <https://review.openstack.org/#/c/324307/>) >> is still not merged. Do I need to spend time on understanding >> it and change plugins deployment tasks >> <https://github.com/openstack/fuel-plugin-nsxv/blob/bab9541d9f13cf80a4796117483e56e94f3a4c09/deployment_tasks.yaml#L1-L10> >> according to the netconfig.pp refactoring? >> >> >> On 6 June 2016 at 11:12, Aleksandr Didenko <adide...@mirantis.com> wrote: >> >>> 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 >>> configuration data in Hiera which any plugin can rely on. >>> >>> I've built a custom ISO with this patch and run a set of custom tests on >>> it to cover multi-role and multi-rack cases [1] plus BVT - everything >>> worked fine. >>> >>> Please feel free to review and comment the patch [0]. >>> >>> Regards, >>> Alex >>> >>> [0] https://review.openstack.org/324307 >>> [1] http://paste.openstack.org/show/508319/ >>> >>> On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko <adide...@mirantis.com >>> > wrote: >>> >>>> 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 >>> >>> >> >> __________________________________________________________________________ >> 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
