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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected] >>> > 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 <[email protected]> >>>> 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 < >>>>> [email protected]> 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 <[email protected]> >>>>>> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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: >>>>>>>> [email protected]?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: >>>>>>> [email protected]?subject:unsubscribe >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> __________________________________________________________________________ >>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>> Unsubscribe: >>>>>> [email protected]?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: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
