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 <green...@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_2...@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_2...@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
