[RFE] Allow to set MTU for networks

Bug #1671634 reported by Ihar Hrachyshka on 2017-03-09
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Ihar Hrachyshka

Bug Description

ATM neutron does allow to configure MTU for networks to reflect underlying infrastructure, but only to operators, and only by changing configuration options.

Ideally, users would be allowed to modify MTU for networks (to simplify matters, on creation only, though we can also look at resource updates) to accommodate for custom workloads relying on specific MTUs. Or maybe sometimes users want to get consistent MTUs across all their networks instead of having different MTUs based on network type backing their networks. Both of those use cases would be served by allowing PUT for 'mtu' network attribute.

I guess it will require a fake extension to signal the change in behavior, even while the implementation may still lay in existing plugin code handling MTUs.

Changed in neutron:
status: New → Triaged
summary: - Allow to set MTU for networks
+ [RFE] Allow to set MTU for networks
Akihiro Motoki (amotoki) wrote :

This really sounds reasonable. I received the same request recently in local meetups.

At now, if operators want to allow users to use a big MTU around 8950 bytes in project networks but want to provide users to 1500 bytes by default, the only way is to disable advertise_mtu in DHCP agent config. In addition, there is no way for regular users to specify a default value for their neutron network.

It sounds reasonable to allow regular users to request network MTU as long as it does not exceed the system limit (which equals to neutron config).

One question is how users can know the maximum allowed MTU but I think it is a different topic.

Changed in neutron:
importance: Undecided → Wishlist
Changed in neutron:
assignee: nobody → Ihar Hrachyshka (ihar-hrachyshka)

Whilst this sounds like a trivial change, I'd like to assess a bit more closely the rationale behind the request. What was the initial reason for keeping the MTU an admin-only right?

Kevin Benton (kevinbenton) wrote :

It wasn't admin-only. It was never writable in the API IIRC.

Yes, the initial MTU blueprint actually meant to make it writable: https://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html (The spec was written by Ian Wells back in the days.) Quoting: "the tenant can request a specific MTU on a network - this is so that, in the case that the tenant has VMs with preconfigured MTUs (for instance, ones that do not respect any of the available forms of MTU advertisement, they can ask for a specifc - typically 1500 - MTU for networks that have these VMs on)."

It just never got implemented.

Aqsa Malik (aqsamm) wrote :

I gave this a try just to see. Would appreciate any feedback

I see https://review.openstack.org/#/c/456663 posted. It's more than that, but posting nevertheless.

Kevin Benton (kevinbenton) wrote :

Let's start with allowing it on create because then we don't need to worry about refreshing interfaces everywhere on an existing network. Then we can look at allowing MTU updates later.

tags: added: rfe-approved
removed: rfe
Changed in neutron:
milestone: none → pike-3

Related fix proposed to branch: master
Review: https://review.openstack.org/483091

Reviewed: https://review.openstack.org/480738
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=28ab6513182af2fe37eb12ddc48a1b06da3f2c5f
Submitter: Jenkins
Branch: master

commit 28ab6513182af2fe37eb12ddc48a1b06da3f2c5f
Author: Ihar Hrachyshka <email address hidden>
Date: Wed Jul 5 13:57:47 2017 -0700

    Moved net-mtu extension definition

    The module is not really imported from anywhere external to neutron, but
    I am going to introduce a new extension that will allow to pass mtu on
    create, and having both defined in a single place should keep it more
    sane.

    Change-Id: I41d5b399a6bd02f89f2e60c5ccb3fc0944b61255
    Related-Bug: #1671634

Changed in neutron:
status: Triaged → In Progress

Related fix proposed to branch: master
Review: https://review.openstack.org/491554

Related fix proposed to branch: master
Review: https://review.openstack.org/491555

Reviewed: https://review.openstack.org/491553
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1da78c924e31b21ed19d10676064c8540929589d
Submitter: Jenkins
Branch: master

commit 1da78c924e31b21ed19d10676064c8540929589d
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Aug 7 10:09:13 2017 -0700

    tests: apply latest release milestone alembic scripts first

    Before walking through migration scripts that belong to the release
    under development, we should first execute all scripts for the latest
    official release because it serves a convergence point. Without it, we
    can't guarantee that calling --expand will succeed because some of new
    scripts may depend on schema state that is defined by contract scripts.

    Change-Id: I501b38900fb2f4409839ecd09be4d937cf20c6a9
    Related-Bug: #1671634

Reviewed: https://review.openstack.org/483518
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f21c7e2851bc99b424bdc5322dcd0e3dee7ee5a3
Submitter: Jenkins
Branch: master

commit f21c7e2851bc99b424bdc5322dcd0e3dee7ee5a3
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Aug 7 10:18:11 2017 -0700

    Allow to set/modify network mtu

    This patch adds ``net-mtu-writable`` API extension that allows to write
    to network ``mtu`` attribute.

    The patch also adds support for the extension to ml2, as well as covers
    the feature with unit and tempest tests. Agent side implementation of
    the feature is moved into a separate patch to ease review.

    DocImpact: neutron controller now supports ``net-mtu-writable`` API
               extension.
    APIImpact: new ``net-mtu-writable`` API extension was added.

    Related-Bug: #1671634
    Change-Id: Ib232796562edd8fa69ec06b0cc5cb752c1467add

Reviewed: https://review.openstack.org/491554
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=cc69828ff09f5dbc37488f3f56bb045772e35634
Submitter: Jenkins
Branch: master

commit cc69828ff09f5dbc37488f3f56bb045772e35634
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Aug 7 10:19:57 2017 -0700

    Apply network MTU changes to l3 ports

    This patch makes L3 agent to update its ports' MTU when it's changed on
    core plugin side.

    Related-Bug: #1671634
    Change-Id: I4444da6358e8b8420a3a365e1107b02f5bb1161d

Reviewed: https://review.openstack.org/491555
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9df067f12d5a66b88728e6af46689050112d9e3a
Submitter: Jenkins
Branch: master

commit 9df067f12d5a66b88728e6af46689050112d9e3a
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Aug 7 10:21:02 2017 -0700

    Apply network MTU changes to dhcp ports

    This patch makes DHCP agent to update its ports' MTU when it's changed
    on core plugin side.

    Related-Bug: #1671634
    Change-Id: Ie1e1ca6a5f908c1e5669ddb3988d49c57da4b9c4

Related fix proposed to branch: stable/pike
Review: https://review.openstack.org/493374

Reviewed: https://review.openstack.org/493373
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=82e421f20e9d9857f46c3b62fb6959d6c5920d7a
Submitter: Jenkins
Branch: stable/pike

commit 82e421f20e9d9857f46c3b62fb6959d6c5920d7a
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Aug 7 10:21:02 2017 -0700

    Apply network MTU changes to dhcp ports

    This patch makes DHCP agent to update its ports' MTU when it's changed
    on core plugin side.

    Related-Bug: #1671634
    Change-Id: Ie1e1ca6a5f908c1e5669ddb3988d49c57da4b9c4
    (cherry picked from commit 9df067f12d5a66b88728e6af46689050112d9e3a)

tags: added: in-stable-pike

Reviewed: https://review.openstack.org/493374
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7298defe704da8c2f5d7642f71246c939facf0a0
Submitter: Jenkins
Branch: stable/pike

commit 7298defe704da8c2f5d7642f71246c939facf0a0
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Aug 7 10:19:57 2017 -0700

    Apply network MTU changes to l3 ports

    This patch makes L3 agent to update its ports' MTU when it's changed on
    core plugin side.

    Related-Bug: #1671634
    Change-Id: I4444da6358e8b8420a3a365e1107b02f5bb1161d
    (cherry picked from commit cc69828ff09f5dbc37488f3f56bb045772e35634)

Reviewed: https://review.openstack.org/483091
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=36464dedfc83193ae705f590a3bfa761aa610b03
Submitter: Jenkins
Branch: master

commit 36464dedfc83193ae705f590a3bfa761aa610b03
Author: Ihar Hrachyshka <email address hidden>
Date: Thu Aug 31 13:36:49 2017 -0700

    Rehome net-mtu-enh extension definition

    This new extension allows to set mtu on create and update. Plugins are
    free to implement only create if needed, returning a meaningful error if
    update is not supported. Plugins should also make sure that MTU makes
    general sense in context of corresponding deployment.

    Plugins supporting the new extension are expected to signal support for
    net-mtu too because the new extension is a superset of the old feature.

    We can't just update the existing net-mtu extension because then support
    for writes is not discoverable.

    Change-Id: I3dd29578cee4ac4f9f55f6500965664e9e8069a6
    Related-Bug: #1671634

Reviewed: https://review.openstack.org/498932
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1a5b796b0639593eaee36be5a7b3ac371884d67d
Submitter: Jenkins
Branch: master

commit 1a5b796b0639593eaee36be5a7b3ac371884d67d
Author: Ihar Hrachyshka <email address hidden>
Date: Tue Aug 29 20:10:12 2017 +0000

    fullstack: skip test_mtu_update when DHCP agent is not in rootns

    The test case requires access to devices created by DHCP agent. When the
    agent is deployed with linuxbridge agent, we start it in a host-
    namespace, and then it creates its own qdhcp- namespaces for dhcp ports
    inside the host- namespace.

    This could be solved by calling:
    ip netns exec host-* ip netns exec qdhcp-* ip link show ...
    but ip_lib doesn't support constructing such commands.

    Of course, we could extend ip_lib to support this use case, but
    currently we have larger dragons to fight. We will revisit the skip once
    all agents are moved to namespaces as planned by jlibosva@.

    This patch merely disables the test case if DHCP agent is running in a
    namespace. We may revisit it when and if we feel comfortable making
    significant changes to ip_lib.

    Change-Id: Ieea83bf2959654f98b1dc4d7aa17138d0626ec40
    Related-Bug: #1671634

Reviewed: https://review.openstack.org/501856
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c62662f3c34dc1db42f1ef07a73269ac7a8a1734
Submitter: Jenkins
Branch: stable/pike

commit c62662f3c34dc1db42f1ef07a73269ac7a8a1734
Author: Ihar Hrachyshka <email address hidden>
Date: Tue Aug 29 20:10:12 2017 +0000

    fullstack: skip test_mtu_update when DHCP agent is not in rootns

    The test case requires access to devices created by DHCP agent. When the
    agent is deployed with linuxbridge agent, we start it in a host-
    namespace, and then it creates its own qdhcp- namespaces for dhcp ports
    inside the host- namespace.

    This could be solved by calling:
    ip netns exec host-* ip netns exec qdhcp-* ip link show ...
    but ip_lib doesn't support constructing such commands.

    Of course, we could extend ip_lib to support this use case, but
    currently we have larger dragons to fight. We will revisit the skip once
    all agents are moved to namespaces as planned by jlibosva@.

    This patch merely disables the test case if DHCP agent is running in a
    namespace. We may revisit it when and if we feel comfortable making
    significant changes to ip_lib.

    Change-Id: Ieea83bf2959654f98b1dc4d7aa17138d0626ec40
    Related-Bug: #1671634
    (cherry picked from commit 1a5b796b0639593eaee36be5a7b3ac371884d67d)

Changed in neutron:
status: In Progress → Won't Fix
status: Won't Fix → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers