[RFE] Ability to migrate a non-Segment subnet to a Segment

[Harald Jensås]

With Neutron segments it is not possible to mix subnets with segment_id: None and subnets with a segment_id. In some cases a network will be created, a subnet added without creating a segment. Then later this network need to scale, and dividing it onto multiple routed segments is required.

To be able to support migration from non-routed to a routed network we would like the ability to migrate subnets on a network with no segments to a segment. The migration can/should be limited to migrating the subnet to a segment that use the same "provider:physical_network".

This feature would enable possibility to upgrade/migrate existing Triplo deployments to neutron routed segments model.

[Armando Migliaccio (armando-migliaccio)]

Interesting use case. I am ambivalent whether or not it's worth the effort.

[Harald Jensås (harald-jensas)]

For my specific use case, it would actually be fine to be able to do this while neutron server, agents where down. E.g if some external util could manipulate the database to migrate subnets in a network into segments so that upon restart of services the subnets had the correct segment_ids.

[Miguel Lavalle (minsel)]

Without routed networks, addresses from the subnet's allocation pools will be assigned to ports that can be bound to any of the corresponding network segments. If later a segment is assigned to the subnet, there is no guarantee that all the ports with addresses from the subnet are bound to to the segment.

I think that the way to implement the scenario described here is to create routed networks from the beginning, with one subnet and segment. As the the need to grow network arises, more subnets and segments can be added.

[YAMAMOTO Takashi (yamamoto)]

Miguel,

I think this RFE is about migration to the starting point.
i.e. from the existing deployment without explicit segments to "a routed network with one subnet and segment"

[Miguel Lavalle (minsel)]

@Harald,

We discussed this RFE in the latest drivers meeting. Can you confirm the following assumptions:

1) Would the network have only one segment?
2) Would the segment to assign to the subnet be the same as the original segment in the network? or
3) Would the segment to be assigned to the subnet be in the same physnet as the original segment in the network?

[Harald Jensås (harald-jensas)]

Yamamoto assumption in #4 is correct, this is about migrating to the starting point. E.g someone set up Openstack Kilo and then upgraded each release until newton; or a later release; with routed networks capabilities. In this scenario the user could not have created routed networks from the beginning, and thus the ability to migrate to the starting point would be beneficial.

1) Would the network have only one segment?

 Yes.

 In the TripleO usecase where I see the benefit to do this we only have on segment in each network.

2) Would the segment to assign to the subnet be the same as the original segment in the network? or
3) Would the segment to be assigned to the subnet be in the same physnet as the original segment in the network?

 I am not sure I fully understand the difference, but either the original segment or a segment with the same same "provider:physical_network" as the original segment in the network.

[Miguel Lavalle (minsel)]

@Harald,

We have approved this RFE. Will you work on the implementation?

[Harald Jensås (harald-jensas)]

@Miquel

I will try to look into it. Might not be very soon tough, as I have some other priorities.

[Harald Jensås (harald-jensas)]

Proposed change in Neutron: https://review.openstack.org/#/c/523972/
Proposed change in python-openstackclient: https://review.openstack.org/#/c/523974/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/527445

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/550920

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/550920
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=9059d0d7097e638fe0947ba964231c6ad2f75922
Submitter: Zuul
Branch: master

commit 9059d0d7097e638fe0947ba964231c6ad2f75922
Author: Harald Jensas <email address hidden>
Date: Tue Dec 12 17:05:00 2017 +0100

    Subnet segment_id writable extension

    To enable the possibility to migrate a non-routed network to a
    routed network allow updating the segment_id of a subnet.

    Change-Id: Iffda823a149a1143f46ee9a05e9640b34bf42c51
    Partial-Bug: #1692490

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/523972
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b6d117fcd577f50a431113c4ad13258a7692e822
Submitter: Zuul
Branch: master

commit b6d117fcd577f50a431113c4ad13258a7692e822
Author: Harald Jensas <email address hidden>
Date: Mon Nov 27 20:57:25 2017 +0100

    Allow setting network-segment on subnet update

    To enable the possibility to migrate a non-routed network to a
    routed network allow updating the segment_id of a subnet.

    Only allow the operation if:
     - The network only has one segment
     - The network only has one subnet
     - The current segment_id == None

    APIImpact: The segment_id attribute of subnets now allows put operation.
    Closes-Bug: #1692490
    Depends-On: Iffda823a149a1143f46ee9a05e9640b34bf42c51
    Change-Id: I1aee29dfb59e9769ec0f1cb1f5d2933bc5dc0dc5

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/527445
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=0f625d427872511145374c01316b348b54990d2c
Submitter: Zuul
Branch: master

commit 0f625d427872511145374c01316b348b54990d2c
Author: Harald Jensas <email address hidden>
Date: Tue Dec 12 17:05:00 2017 +0100

    Update api-ref to reflect update allowed for subnet segment_id

    Depends-On: I1aee29dfb59e9769ec0f1cb1f5d2933bc5dc0dc5
    Change-Id: Ifbb6c7101ceda9d300c4d0eebd9f016309bfe761
    Partial-Bug: #1692490

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 13.0.0.0b2 development milestone.