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
