On Thu, 2018-03-29 at 14:20 -0700, Gregory Farnum wrote: > > Since Sage was inclined the other way, it’s worth calling out that > the > opportunity cost of handling map epochs seems to be negligible. And > if > we don’t do that work, any future change to the monitors will require > special handling for old clients. :) Either way, we'll be stuck with one or the other approach in case of future monitor changes: - if we go with Sage's first suggestion, we'll always have to be extra careful to ensure subscription updates are always serialized after map updates, which is easy enough to do but hard to correctly test. - if we go with the second suggestion, we'll end up with more fields in MMonCommand, which we will have to support in case we change things at some point, but I think this is actually a lot easier to test/ensure correctness. The problem with the second one, as Sage mentioned, is that some commands do change multiple maps in the monitors, and replying with only one version to the client can be weird. E.g., "ceph osd new" may change auth on top of the osdmap. As we add more commands that change several maps, this may only increase in complexity. And returning just one version can be weird at some point. I'd suggest going with the second option nonetheless, with a twist: instead of replying with just one version, reply with a version map. Let the client care about which map versions they really want. This also means not (re)using the PaxosServiceMessage's version field, but add a new field instead, which can make it easier to handle in case of future rework of this code path given we're not going out of our way to factor that existing field into the command's architecture. -Joao -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
