<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 July 2017 at 14:14, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Heya,<br>
<br>
we have <a href="https://bugs.launchpad.net/neutron/+bug/1671634" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>neutron/+bug/1671634</a> approved for<br>
Pike that allows setting MTU for network on creation. </blockquote><div><br></div><div>This was actually in the very first MTU spec (in case no one looked), though it never got implemented.  The spec details a whole bunch of stuff about how to calculate whether the proposed MTU will fit within the encap, incidentally, and will reject network creations when it doesn't.</div><div><br></div><div>Note that the MTU attribute was intended to represent an MTU that will definitely transit.  I guess no-one would actually rely on this, but to clarify, it's not intended to indicate that bigger packets will be dropped, only that smaller packets will not be dropped (which is the guarantee you need for two VMs to talk to each other.  Thus the MTU doesn't need to be increased just because the infrastructure MTU has become larger; it just means that future networks can be created with larger MTUs from this point, and the current MTU will still be valid.</div><div><br></div><div>This is also the MTU that all VMs on that network will be told, because they need to use the same value to function.  If you change it, VMs after the event will have problems talking to their earlier friends because they will now disagree on MTU (and routers will have problems talking to at least one of those sets).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(but not update,<br>
as per latest comment from Kevin there) I already see a use case to<br>
modify MTU for an existing network (for example, where you enable<br>
Jumbo frames for underlying infrastructure, and want to raise the<br>
ceiling; another special case is when you migrate between different<br>
encapsulation technologies, like in case of ml2/ovs to networking-ovn<br>
migration where the latter doesn't support VXLAN but Geneve only).<br></blockquote><div><br></div><div>You look like you're changing the read-only segmentation type of the network on this migration - presumably in the DB directly - so you're changing non-writeable fields already.  Couldn't the MTU be changed in a similarly offline manner?</div><div><br></div><div>That said: what will you do with existing VMs that have been told the MTU of their network already?</div><div><br></div><div>Put a different way, a change to the infrastructure can affect MTUs in two ways:</div><div><br></div><div>- I increase the MTU that a network can pass (by, for instance, increasing the infrastructure of the encap).  I don't need to change its MTU because VMs that run on it will continue to work.  I have no means to tell the VMs they have a bigger MTU now, and whatever method I might use needs to be 100% certain to work or left-out VMs will become impossible to talk to, so leaving the MTU alone is sane.</div><div>- I decrease the MTU that a network can pass (by, for instance, using an encap with larger headers).  The network comprehensively breaks; VMs frequently fail to communicate regardless of whether I change the network MTU property, because running VMs have already learned their MTU value and, again, there's no way to update their idea of what it is reliably.  Basically, this is not a migration that can be done with running VMs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I go and implement the RFE as-is, and later in Queens we pursue<br>
updating MTU for existing networks, we will have three extensions for<br>
the same thing.<br>
<br>
- net-mtu (existing read only attribute)<br>
- net-mtu-enhanced (allow write on create)<br>
- net-mtu-enhanced-enhanced (allow updates)<br>
<br>
Not to mention potential addition of per-port MTU that some folks keep<br>
asking for (and we keep pushing against so far).<br>
<br>
So, I wonder if we can instead lay the ground for updatable MTU right<br>
away, and allow_post: True from the start, even while implementing<br>
create only as a phase-1. Then we can revisit the decision if needed<br>
without touching api. What do you think?<br></blockquote><div><br></div><div>It's trivially detectable that an MTU value can't be set at all, or can be set initially but not changed.  Could we use that approach?  That way, we don't need multiple extensions, the current one is sufficient (and - on the assumption that you don't rely on 'read-only attribute' errors in normal code, I think we can call this backward compatible).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another related question is, how do we expose both old and new<br>
extensions at the same time? I would imagine that implementations<br>
capable of writing to the mtu attribute would advertise both old and<br>
new extensions. Is it correct? Does neutron api layer allow for<br>
overlapping attribute maps?<br></blockquote><div><br></div><div>Extension net-mtu: MTU attr exists, can't set MTU at all, passing an MTU returns a bad argument error</div><div>Extension net-mtu: MTU attr exists, can set MTU on startup, failed (too big) MTU values return a more specific MTU too big error</div><div>Extension net-mtu: MTU attr exists, can set after creation, setting MTU after creation fails as for startup write (which it appears you already have in mind)</div><div><br></div><div>-- </div><div>Ian.</div></div></div></div>