Peter Xu <pet...@redhat.com> wrote: ...
>> > Here what I wanted to achieve is that: >> > >> > a. for postcopy, we should try to enable return path, and it must >> > succeed >> > >> > b. for the case when enable_return_path is set, we try to enable return >> > path, but even if it failed, we can still continue >> > >> > Could we really achieve (b) if with above code? Or anything I missed? >> >> if we enable_return_path -> it should success, otherwise it makes no >> sense, no? We can try to remove the return path for some transports if >> needed, but it makes no sense to enable a property that means: >> "please, pretty please, enable it if you can" > > (Indeed this is awkward... :) > >> >> if we are going to do it that way, then it is better to change the >> property the other way around: >> >> - disable_return_path: set for all old machine types >> >> And not set for newer machine types, meaning that we just try. >> >> What do you think? > > Both namings work for me. > > The problem is that we cannot really force this as long as there is > any type of transports that does not support return path. E.g., when > migrating to an "exec:" typed transport with single-out IO stream. In > that case, if we fail the migration, it'll break the old behavior, > right? Then for exec: typed users they need to manually provide > enable_return_path=false to finally allow them to migrate. > > (I think that's the most tricky point of this series...) Then do what I said. Disable it for old machine types. And for new machine types, we just try our best. What I object is having a property with a meaning of "perhaps enable return path". And yes, representing with a boolean a tri-state is tricky O:-) Later, Juan.
