cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anuj Wadehra <anujw_2...@yahoo.co.in>
Subject Re: Revisit Cassandra EOL Policy
Date Fri, 08 Jan 2016 16:37:11 GMT
Thanks Mark!!"My sense is that most users manage their own C* clusters, not dozens of other
ones for other clients/customers"In our case, product is released to several customers and
thus, every Cassandra upgrade needs planning, packaging, multiple product testing cycles &
release. 

"One would hope it's via some sort of automation framework like Chef or something to help
out with some of the heavy lifting."We don't use Chef.
ThanksAnuj
 

    On Thursday, 7 January 2016 10:08 PM, Mark Greene <greenemj@gmail.com> wrote:
 

 Being on this mailing list for several years now, I would take a guess that most of the users
here probably don't have a use case that aligns with yours. My sense is that most users manage
their own C* clusters, not dozens of other ones for other clients/customers.

For my own use cases, I manage C* infrastructure for just one company and given the amount
of bug fixes that have occurred in the 2.1.X versions, I'm glad it's moving fast and honestly
not interested in staying on any old versions. I think a quick glance of the change logs would
probably change your mind a bit. I think this really just the reality of a lot of the OSS
out there. This stuff just moves so quickly that staying on old versions is pretty risky and
catching up becomes a non-trivial task. We just chalk it up to the investment required for
the technology selection. If we want to store vasts amount of data, not pay for the software,
a reasonable person has to expect some kind of investment from their side. 

To your point, supporting old versions is a pain. It really is. I can't imagine how many more
bugs would arise by adopting some crazy convoluted EOL policy that forced C* developers to
carry tech debt around for a long period of time. 

We update C* about every 3 months or earlier depending on if we are impacted by a bug. It
takes all but a few hours to do so it's not bad at all. Our move to 3.X will require far more
effort but we don't anticipate making those sorts of big changes frequently so it's reasonable.

You didn't make any mention to how you manage all of your C* infrastructure. One would hope
it's via some sort of automation framework like Chef or something to help out with some of
the heavy lifting. 





On Wed, Jan 6, 2016 at 8:26 PM, Anuj Wadehra <anujw_2003@yahoo.co.in> wrote:

I would appreciate if you guys share your thoughts on the concerns I expressed regarding Cassandra
End of Life policy. I think these concerns are quite genuine and should be openly discussed
so that EOL is more predictable and generates less overhead for the users.
I would like to understand how various users are dealing with the situation. Are you upgrading
Cassandra every 3-6 mths? How do you cut short your planning,test and release cycles for Cassandra
upgrades in your application/products?



ThanksAnuj


 
 
 On Tue, 5 Jan, 2016 at 8:04 pm, Anuj Wadehra<anujw_2003@yahoo.co.in> wrote:   Hi,
As per my understanding, a Cassandra version n is implicitly declared EOL when two major versions
are released after the version n i.e. when version n + 2 is released.
I think the EOL policy must be revisted in interest of the expanding Cassandra user base. 
Concerns with current EOL Policy:
In March 2015, Apache web site mentioned that 2.0.14 is the most stable version of the Cassandra
recommended for Production. So, one would push its clients to upgrade to 2.0.14 in Mar 2015. It
takes months to roll out a Cassandra upgrade to all your clients and by the time all your
clients get the upgrade, the version is declared EOL with the release of 2.2 in Aug 2015 (within
6 mths of being declared production ready). I completely understand that supporting multiple
versions is tougher but at the same time it is very painful and somewhat unrealistic for users
to push Cassandra upgrades to all thier clients after every few months.
One proposed solution could be to declare a version n as EOL one year after n+1 was declared
Production Ready. E.g. if 2.1.7 is the first production ready release of 2.1 which is released
in Jun 2015, I would declare 2.0 EOL in Jun 2016. This gives reasonable time for users to
plan upgrades.
Moreover, I think the EOL policy and declarations must be documented explicitly on Apache
web site.
Please share your feedback on revisting the EOL policy.
ThanksAnuj
  




  
Mime
View raw message