One thing probably worth thinking about: we're a mostly irascible lot to
begin with and there's a global pandemic and Human Race Lockdown. I don't
know about the rest of you but I'm starting from a pretty not-chill place
these days; trying to be mindful of that.
So for this: if we require a protoc
Hi,
first of all I think that we should not reinvent the wheel here. I
think that I am not far from the truth when I say that Orange's
operator is the most mature one when it comes to features and the most
battle-tested. I have not checked how it is done in details internally
yet but I am satisfie
Whether a feature is fully done and whether it validates or invalidate
testing is not the point here. The point is that it is a feature and
violates feature freeze. If someone brings in a feature which is almost
done and does not invalidate testing then will we merge all of them to 4.0?
Lot of feat
Chris's original patch used a virtual table which didn't even require a
protocol change. To me, the difference between having a CQL describe vs a
virtual table is unimportant, since it's only drivers that need to care
about it. I'm completely fine with the simpler implementation of a virtual
tabl
So summarizing the salient points here:
- client authors have worked around this mostly, but this would avoid some
duplication of effort for new features
- this issues was tagged last year as being pertinent to 4.0 in several
threads about what was in scope
- there is some development efforts requi
Yeah, I feel like it’s a bad example to use to highlight 4.0 scope creep (which
is less of a thing than some fear).
The work there is already done, and it’s extremely unintrusive. There is no
reason whatsoever to block 4.0 on it, but no reason not to commit - now, in a
beta, in the first RC, or
Sorry if this is a repeat message; I messed up my mail client settings (I don't
see it today, but it might just be stuck in an unmonitored moderator queue):
I think it is unfair to label this scope creep; it would have to be newly
considered for 4.0 for it to fall under that umbrella, surely?
I
Hi all,
We at Orange would love to be included in these talks about a unique Kubernetes
operator for Cassandra.
It comes a bit late for us as we have spent a couple of years on ours and are
close to running it in production but moving to a community supported one will
be better for everybod
+1 for shipping it after 4.0
On Thu, Apr 2, 2020 at 12:39 AM Jon Haddad wrote:
> Most of the work to provide this feature is already done. We need to
> generate server side CQL for snapshots already. All we need to do is
> expose it via either a "DESCRIBE" CQL command, or I'm equally happy t
