For all of these we should be able to support a rolling upgrade from 1.x with some caveats. 1) There are a few possibilities on how to make this happen, but none of them are ideal. If you feel strongly about a rolling upgrade I might skip this. 2) would work for all workers that do not access objects from storm.thrift directly. (which I think should be most topologies)
3) Would require us to do changes similar to what we did when we first shaded everything. Have users compile their topologies against the newer version of storm, but override some dependencies to match the older version of storm. Then when it is deployed it could run on either version of storm. - Bobby On Monday, November 7, 2016, 3:56:08 AM CST, Harsha Chintalapani <st...@harsha.io> wrote:My only concern here is the rolling upgrade of storm cluster. We supported the rolling upgrade going to 0.10 and broke it because of storm 1.x release. Users are not inclined to upgrade to a new release if it's not rolling upgradable. In this case, it looks like we are going to break this. Correct me if I am wrong here. Thanks, Harsha On Mon, Nov 7, 2016 at 7:43 AM Bobby Evans <ev...@yahoo-inc.com.invalid> wrote: > Made a mistake and put something on private that never should have been > there. Here is the discussion in full so far. > In response to Jungtake removing the nocamel option will change > set_bar/get_bar in the generated thrift code to setBar/getBar. So any > thrift object that clients interact with will need to make similar changes. > - Bobby > > ----- Forwarded Message -----From: Bobby Evans <ev...@yahoo-inc.com>To: " > priv...@storm.apache.org" <priv...@storm.apache.org>Sent: Monday, > November 7, 2016, 3:37:50 AM CST Subject: Re: [DISCUSS] breaking changes in > 2.x > Sorry you are right, I put in the wrong mailing list. I feel dumb. Will > move it to dev. > - Bobby > > On Sunday, November 6, 2016, 2:18:33 AM CST, P. Taylor Goetz < > ptgo...@gmail.com> wrote:Can we move this discussion to dev@? There > doesn't seem to be anything sensitive about the subject. > -Taylor > On Nov 6, 2016, at 1:28 AM, Jungtaek Lim <kabh...@gmail.com> wrote: > > > Regarding breaking change, I'm OK to break backward UX compatibility if > we're sure that it gives better UX. And since we're talking about next > major, if we don't do it now, we might have no chance to do the near future. > For 1) this should be corrected, and for 2) I'm not sure how it affects to > end-users, but it would be better to address if it doesn't hurt user codes > much. 3) I think expected user impact is similar to what we did it for > adding dependencies to shade list. Then it doesn't look matter to me. > Thanks,Jungtaek Lim (HeartSaVioR) > 2016년 11월 5일 (토) 오후 11:01, Bobby Evans <bo...@apache.org>님이 작성: > > I have been working on getting some of clojure code translated to java, > and I have run into a few issues that I really would like to address, but > will impact users. Because 2.x has not been released yet technically these > should be OK, but I want to get feedback from others before I spend a lot > of time on them or even file a JIRA. > 1)WHAT: The thrift NodeInfo.port should be a single long, not a set of > longs.USER IMPACT: it is exposed to end users through the profiling request > API. BACK COMPAT: it is possible, but I would prefer not to. > > 2)WHAT: Using 'nocamel' when generating thrift makes generated exceptions > less useful and the API less java like.USER IMPACT: users when upgrading > would need to modify some API calls when setting/reading thrift > objects.BACK COMPAT: most older clients should still work for a lot of > things > 3) WHAT: split up storm-core so we have class path separation between > daemons and a true client.USER IMPACT: Users may need to include new > dependencies to get what they want. Old topologies may not get access to > everything that they want.BACK COMPAT: we could leave some old > dependencies in place that are not needed, but why? > If we do all of these it is likely that profiling requests from an old > client will not work, but for the most part a 1.x client would still work > with 2.x. > - Bobby > >
