Open Stack

  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160607/bb37eaf2/attachment.html>