Open Stack

Heya,

we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for
Pike that allows setting MTU for network on creation. (but not update,
as per latest comment from Kevin there) I already see a use case to
modify MTU for an existing network (for example, where you enable
Jumbo frames for underlying infrastructure, and want to raise the
ceiling; another special case is when you migrate between different
encapsulation technologies, like in case of ml2/ovs to networking-ovn
migration where the latter doesn't support VXLAN but Geneve only).

If I go and implement the RFE as-is, and later in Queens we pursue
updating MTU for existing networks, we will have three extensions for
the same thing.

- net-mtu (existing read only attribute)
- net-mtu-enhanced (allow write on create)
- net-mtu-enhanced-enhanced (allow updates)

Not to mention potential addition of per-port MTU that some folks keep
asking for (and we keep pushing against so far).

So, I wonder if we can instead lay the ground for updatable MTU right
away, and allow_post: True from the start, even while implementing
create only as a phase-1. Then we can revisit the decision if needed
without touching api. What do you think?

Another related question is, how do we expose both old and new
extensions at the same time? I would imagine that implementations
capable of writing to the mtu attribute would advertise both old and
new extensions. Is it correct? Does neutron api layer allow for
overlapping attribute maps?

Ihar