Open Stack

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 <izinovik at 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 <adidenko at 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 <adidenko at 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 <spasquier at 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 <aheczko at 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 <
>>>>> adidenko at 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 <aheczko at 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 <
>>>>>>> adidenko at 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 <
>>>>>>>> adidenko at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160607/906ccd2f/attachment.html>