If we want users to upgrade to new version, the rolling upgrade is a major decision factor. As a community, we need to look API updates or breaking changes much more diligently. I agree to an extent we shouldn't limiting ourselves with rolling upgrade. But having announced rolling-upgrade in 0.10 and then not supporting it in 1.x and now in 2.x. In User's point of view, Storm is not rolling upgradable although we shipped a release stating that rolling upgrade is supported and in follow-up release we taken that off. Does these API changes are critical and worth breaking rolling upgrade?
-Harsha On Mon, Nov 7, 2016 at 9:16 AM Kyle Nusbaum <[email protected]> wrote: I worry that making it a priority to have rolling upgrades between major versions significantly restricts the kinds of changes that we can make, including some kinds of changes that a major version increment is supposed to mark. I'm not really in support of trying to do that. If we can't make changes that break compatibility now, when can we make them? Can changes like that ever be made? I don't know that it's good to limit ourselves like that. Trying to accommodate rolling upgrades is a good idea, but I'm not sure about rejecting code changes across major versions to support them. 2.x represents a large shift in the project, and I expect once the translation, etc. is done, things will calm down and APIs will become more stable, allowing more of our future releases to be rolling even across major versions. I'd rather get these kinds of changes out of the way now in the 2.x release than cart along the vestiges of 1.x from now on. What do others think about this? -- Kyle On Monday, November 7, 2016, 3:10:08 AM CST, Bobby Evans <[email protected]> wrote:Let's distinguish between wire compatibility changes and API compatibility changes, along with impact to workers vs impact to clients. For 3) splitting the classpath up for each daemon wire compatibility is not impacted, but we are potentially removing a bunch of APIs from the worker and client classpath. Most of these where shaded and users should not be impacted by them being removed, but a few like servlet-api-2.5.jar are likely to be removed. So yes the impact here would likely be very small. However on the client side if a topology wants to include LocalCluster (like we do in a lot of examples) the topology jar will get a lot bigger. LocalCluster needs access to nimbus, supervisor, and drpc server. These would not be on the worker classpath any more and would then need to be packaged into the topology jar to make LocalCluster work. In production I would expect LocalCluster to be used by tests and not be included like we do in a lot of examples. This is more of a shift for how we expect users to interact with the LocalCluster. For 1) NodeInfo.port depending on how we do it, it could break wire compatibility and API compatibility (which is what I would prefer). We could play some games to maintain compatibility, but for me it is enough of a pain that I am not sure it is worth it. However this is not likely to impact workers because they don't use these APIs directly. It might impact clients but only if they have custom code to profile their topologies. IF they use the build in CLI/UI it would not be impacted. For 2) nocamel would break API compatibility, but not wire compatibility. This is not likely to impact workers because like with 1 workers don't really interact with nimbus directly so it would not be a problem. Old clients running with older versions of storm would continue to work, but any custom client code (think what gets run by storm jar) would need to be recompiled/modified to be able to run on against a storm-2.x client. - Bobby
