>> I think CEP should be more upfront with "eventually replace
>> it" bit, since it raises the question about what the people who are
using
>> other index implementations can expect.
Will update the CEP to emphasize: SAI will replace other indexes.
>> Unfortunately, I do not have an
>> implement
FWIW, I personally look forward to receiving that contribution when the time is
right.
On 23/09/2020, 18:45, "Josh McKenzie" wrote:
talking about that would involve some bits of information DataStax might
not be ready to share?
At the risk of derailing, I've been poking and proddi
tl;dr Setting encryption_options.protocol does not control which TLS
protocols are accepted, only restricting cipher_suites by protocol
does and I think we should fix encryption_options.protocol to actually
restrict, and have a proposal to do so at the end of the email.
I've been investigating re
Perhaps it helps to widen the field of discussion to the dev list?
It might help if each of the stakeholder organisations state their view on the
situation, including why they would or would not support a given
approach/operator, and what (preferably specific) circumstances might lead them
to c
talking about that would involve some bits of information DataStax might
not be ready to share?
At the risk of derailing, I've been poking and prodding this week at we
contributors at DS getting our act together w/a draft CEP for donating the
trie-based indices to the ASF project.
More to come; t
As long as we can construct the on-disk indexes efficiently/directly from a
Memtable-attached index on flush, there's room to try other data
structures. Most of the innovation in SAI is around the layout of postings
(something we can expand on if people are interested) and having a natively
row-ori
I did see a bit about "future parity and beyond" which is more or less an
obvious goal. I think CEP should be more upfront with "eventually replace
it" bit, since it raises the question about what the people who are using
other index implementations can expect.
On Wed, Sep 23, 2020 at 6:00 PM Jere
I want to point out that pretty much everything being discussed in this
thread has been discussed at length during the SIG meetings. I think it is
worth noting because we are pretty much still have the same conversation.
On Wed, Sep 23, 2020 at 12:03 PM Benedict Elliott Smith
wrote:
> I don't t
I W
On Wed, Sep 23, 2020 at 12:03 PM Benedict Elliott Smith
wrote:
> I don't think there's anything about a code drop that's not "The Apache
> Way"
>
> If there's a consensus (or even strong majority) amongst invested parties,
> I don't see why we could not adopt an operator directly into the pr
I don't think there's anything about a code drop that's not "The Apache Way"
If there's a consensus (or even strong majority) amongst invested parties, I
don't see why we could not adopt an operator directly into the project.
It's possible a green field approach might lead to fewer hard feelings
> Short question: looking forward, how are we going to maintain three 2i
> implementations: SASI, SAI, and 2i?
I think one of the goals stated in the CEP is for SAI to have parity with 2i
such that it could eventually replace it.
> On Sep 23, 2020, at 10:34 AM, Oleksandr Petrov
> wrote:
>
>
Short question: looking forward, how are we going to maintain three 2i
implementations: SASI, SAI, and 2i?
Another thing I think this CEP is missing is rationale and motivation
about why trie-based indexes were chosen over, say, B-Tree. We did have a
short discussion about this on Slack, but both
I think that from Instaclustr it was stated quite clearly multiple
times that we are "fine to throw it away" if there is something better
and more wide-spread.Indeed, we have invested a lot of time in the
operator but it was not useless at all, we gained a lot of quite
unique knowledge how to put a
I can explain quite a bit of the history of why we are in this situation today
if you want but the important question is:
Who is willing to donate its operator and the control over its future to the
community?
- Orange does with CassKop, as soon as we release v1 quite soon.
- who else? and when?
> I think there's significant value to the community in trying to coalesce
on a single approach,
I agree. Unfortunately in this case, the parties with a vested interest and
written operators came to the table and couldn't agree to coalesce on a
single approach. John Sanda attempted to start an init
I think there's significant value to the community in trying to coalesce on a
single approach, earlier than later. This is an opportunity to expand the
number of active organisations involved directly in the Apache Cassandra
project, as well as to more quickly expand the project's functionality
16 matches
Mail list logo
