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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
