[
https://issues.apache.org/jira/browse/STORM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384145#comment-15384145
]
ASF GitHub Bot commented on STORM-634:
--------------------------------------
Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/414
@danny0405 That is very similar to what we want to move towards in our
rolling upgrades. We have done a very good job of maintaining compatibility of
LS and ZK once we moved to thrift for all of them. There were a few hiccups at
the beginning, but none of those were officially released. Because of feature
work we do/etc we typically don't run "official" releases of apache storm, but
code that is based off of an official release + a bunch of other stuff. This
is what bit us once as we were working on adding in support for rolling
upgrades and had to start clearing the local state on the node. This should
not be a problem, especially if you stick with official releases.
> Storm should support rolling upgrade/downgrade of storm cluster.
> ----------------------------------------------------------------
>
> Key: STORM-634
> URL: https://issues.apache.org/jira/browse/STORM-634
> Project: Apache Storm
> Issue Type: Dependency upgrade
> Components: storm-core
> Reporter: Parth Brahmbhatt
> Assignee: Parth Brahmbhatt
> Fix For: 0.10.0
>
>
> Currently when a new version of storm is released in order to upgrade
> existing storm clusters users need to backup their existing topologies , kill
> all the topologies , perform the upgrade and resubmit all the topologies.
> This is painful and results in downtime which may not be acceptable for
> "Always alive" production systems.
> Storm should support a rolling upgrade/downgrade deployment process to avoid
> these downtimes and to make the transition to a different version effortless.
> Based on my initial attempt the primary issue seem to be the java
> serialization used to serialize java classes like StormBase, Assignment,
> WorkerHeartbeat which is then stored in zookeeper. When deserializing if the
> serial versions do not match the deserialization fails resulting in processes
> just getting killed indefinitely. We need to change the Utils/serialize and
> Utils/deserialize so it can support non java serialization mechanism like
> json.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
