On Mon, 20 Jan 2025 at 02:16, Jeff Jirsa wrote:
> IIRC Cassandra is configured such that only PMC members can roll a release
>
FTR, it's only the very final step of pushing the release artefacts public
that only the PMC can do. Any committer can initiate and lead the release
process at large.
I will be working on the release with Francisco.
On Sun, Jan 19, 2025 at 5:16 PM Jeff Jirsa wrote:
> IIRC Cassandra is configured such that only PMC members can roll a release
>
> Who on the PMC is actually doing the sidecar release?
>
>
> > On Jan 20, 2025, at 12:47 AM, Francisco Guerrero
> wr
IIRC Cassandra is configured such that only PMC members can roll a release
Who on the PMC is actually doing the sidecar release?
> On Jan 20, 2025, at 12:47 AM, Francisco Guerrero wrote:
>
> Hi folks,
>
> I wanted to give an update on where we are with the release. After
> some delays last
Hi folks,
I wanted to give an update on where we are with the release. After
some delays last year, we've finally merged the authorization PR
into Sidecar. My focus this week is to try to merge any pending PR
that will be included as part of the first release, and the following
week I will work on
Hi all,
I sincerely want to thank everyone who chimed in on this thread and the
slack conversation.
I want to make sure that I cover the background on CEP-1 for posterity's
sake. Cassandra Sidecar was proposed as a component / sub-project prior to
the existence of CEP. The discussion around this
Just bringing this back to the list. Patrick, Francisco, Jon and I
discussed this a bit over in slack [1] and I think we got to a rough
consensus that:
1. We're going to leave CEP-1 archived, if someone calls out functionality
in the current sidecar code they think is problematic we'll open a
disc
Oh I didn't agree we needed a new CEP, I thought we were agreeing on
focusing on releasing the sidecar as is. CEP-1 was already voted on, we
built consensus on the controversial part (having functionality outside the
main process) and developers already started the project many years ago and
teams
> The process we all agreed to is being avoided, so I hope we can get back on
> track here.
Words matter. I don't think anyone is avoiding anything here, I think CEP-1 was
a first draft, way too large, and it's been chaotic and confusing to transition
from that to where we are now with a realist
It's less the release than the community agreeing to what is being
released. If this is an official Cassandra project, the PMC has
oversight and there needs to be a consensus vote on what we are
including in the project. Even pre-existing code that was donated as a
sub-project has gone through the
Hi Patrick,
Correct me if I'm wrong, but I don't think there's any precedent
on creating a CEP for a release. My understanding is that releases
are driven by release vote.
Best,
- Francisco
On 2024/11/15 20:04:10 Patrick McFadin wrote:
> Just a reminder of the CEP. That's something that needs to
Just a reminder of the CEP. That's something that needs to be
completed and voted on before any release.
Patrick
On Fri, Nov 15, 2024 at 11:46 AM Francisco Guerrero wrote:
>
> Hi community,
>
> Saranya and I wanted to give an update on where things stand
> with the Sidecar release. We've been wo
Hi community,
Saranya and I wanted to give an update on where things stand
with the Sidecar release. We've been working towards completing
the remaining JIRAs[1][2][3][4][5][6] in preparation for the Sidecar
release.
We've already completed the authentication piece [7] and it has been
merged as o
I have moved the original CEP-1 to the Archived section of Confluence:
https://cwiki.apache.org/confluence/x/gImzBQ
You can go ahead a create v2 of CEP-1 using the CEP template.
Patrick
On Tue, Oct 15, 2024 at 10:12 AM Josh McKenzie wrote:
> Should make sure we snapshot it and/or history reten
Should make sure we snapshot it and/or history retention is sufficient for us
to preserve the effort that went into the original. To Joey's point, there's a
lot of hard work that went into it as it stands it'd be a shame to lose.
On Tue, Oct 15, 2024, at 1:07 PM, Dinesh Joshi wrote:
> My prefere
That's a reasonable approach. I'm +1 with updating CEP-1 and closing it when
we release Sidecar.
On 2024/10/15 17:07:58 Dinesh Joshi wrote:
> My preference would be to simply update CEP-1 instead of starting a new
> one. It achieves the same end goal and we can create new CEPs for the scope
> that
My preference would be to simply update CEP-1 instead of starting a new
one. It achieves the same end goal and we can create new CEPs for the scope
that is deferred.
Dinesh
On Mon, Oct 14, 2024 at 4:51 PM Patrick McFadin wrote:
> I think that all sounds good. Let's get that new CEP started then
I think that all sounds good. Let's get that new CEP started then. I think
there are opinions flying around based on last week's discussions that need
to coalesce.
Patrick
On Mon, Oct 14, 2024 at 3:19 PM Francisco Guerrero
wrote:
> From my point of view CEP-1 is overly broad in terms it wants t
>From my point of view CEP-1 is overly broad in terms it wants to achieve.
My understanding is that CEPs have to have a well-defined scope.
I agree with Joey that we should close CEP-1 with the features I have
proposed earlier in this thread. And have any future Sidecar work captured in
subsequent
Hi everyone!
I am curious what Dinesh's perspective is but I think the specific
enumerated scope in CEP-1 isn't super critical to be honest. That CEP
successfully (imo) built consensus that the community wants a separate
management process, and that sidecar both exists today and has useful
functio
What are we going to do with CEP-1? Cut and rescope in a new CEP or rewrite
CEP-1?
On Mon, Oct 14, 2024 at 11:18 AM Francisco Guerrero
wrote:
> Hi folks,
>
> It was great meeting some of you in person at Community over Code where
> we had a chance to discuss the Cassandra Sidecar project. A lot
Hi folks,
It was great meeting some of you in person at Community over Code where
we had a chance to discuss the Cassandra Sidecar project. A lot of
you expressed interest in having a release of Sidecar to start using the
existing features in the project:
- C* adapters for versions 4.0, 4.1, 5.0
I'm tentatively in favor of the idea of us cutting releases for all our
ecosystem dependencies as a blocker to cutting a major with Cassandra proper. I
say tentatively since we've had trouble getting majors across the line for
awhile so adding more dependencies to that feels risky, however I thi
> Mostly Analytics, which should not be a blocker for Sidecar.
Yes, agreed. I'm just trying to understand the context of the vnode
statement and how we're framing 1.0 sidecar.
> We definitely need to support 5.0 for the Analytics release, but that's
orthogonal to Sidecar.
It is, unless we're en
> By vnode support, do you mean the analytics library? Or do other features
> in sidecar not work with vnodes?
Mostly Analytics, which should not be a blocker for Sidecar. However, I do
feel there should be more testing around vnodes in Sidecar.
> If we're talking about analytics, that gets a li
By vnode support, do you mean the analytics library? Or do other features
in sidecar not work with vnodes?
If we're talking about analytics, that gets a little complicated. Are we
also then talking about 1.0'ing analytics? If so, I think we need support
for 5.0 and BTI there.
In my opinion, if
Hi folks,
Thanks for all the input. I'm trying to gather all the comments, and from what I
can gather it seems that most of the opinions are converging towards scoping
a Sidecar release. These are the items that were called out that we will need
for a release:
- Documentation
- Authorization / Aut
When I developed some of the original sidecar code, it was based on REST
Easy, which would have allowed us to generate the spec automatically. I
did this in a similar project.
That was removed here:
https://issues.apache.org/jira/browse/CASSANDRASC-57
But unfortunately it looks like you can't ge
Something like this:
https://instaclustr.github.io/instaclustr-icarus-go-client/
On Wed, Oct 2, 2024 at 4:54 PM Štefan Miklošovič
wrote:
> While documenting endpoints please use something like OpenAPI
> specification. The sidecar should expose this document itself so when I go
> to this and tha
While documenting endpoints please use something like OpenAPI
specification. The sidecar should expose this document itself so when I go
to this and that URL, I see all endpoints, I put the payloads / parameters
for them and I can just directly call that, no messing with curl / wget or
programmatic
Hi Abhijeet,
Contributing documentation would be greatly appreciated.
Feature wise - is there functionality in sidecar that I missed? What are
you finding to be quite useful? I think everyone would benefit to hear
from folks who use it and are getting something useful out of it as it will
help
Hi folks,
I have been using Sidecar recently and have found some of its
functionalities to be quite useful. Hari and I are also working on CEP-40
which aims to introduce live migration features in Sidecar in the
near future.
However, as others have mentioned, I agree that it currently lacks prope
Totally agree with Jon here basically on all fronts. Apache Cassandra
Sidecar was always a hard nut to crack for me, that is probably why I have
not been involved with that a lot even that is a great tool to have and be
invested in as I was writing my own sidecar and I found a lot of
similarities a
I don't think we should release sidecar 1.0 without any docs.
I took a look through the closed JIRAs to see what's there. Here's what I
found, please correct me if there's more:
- Lots of stuff related to analytics.
I would be pretty excited for this, but the analytics library only works
with s
Currently the Sidecar has a lot of functionality that is immediately usable
by the community. Apart from minor fixes, the AuthN/Z story would be
wrapped up soon. Post this, I would propose moving forward with cutting a
release with the existing feature set so we can get this in the hands of
our com
Have the same question ： what ‘s the plan ？
Jeff Jirsa 于2024年10月2日 周三上午10:43写道：
>
>
> On Oct 1, 2024, at 7:26 PM, Josh McKenzie wrote:
>
> However it is used by a number of other features as a dependency such as
> analytics, backup/restore, repair, metrics, and CDC
>
> It seems like a natural pr
> On Oct 1, 2024, at 7:26 PM, Josh McKenzie wrote:
>
>> However it is used by a number of other features as a dependency such as
>> analytics, backup/restore, repair, metrics, and CDC
> It seems like a natural pressure relief valve for moving operations out of a
> core C* node that are well s
gt;>>>>
>>>>> 1 - Re-furbish CEP-1 and start a [DISCUSS] thread
>>>>> 2 - Close out CEP-1 and Propose something fresh and start a [DISCUSS]
>>>>> Thread on that.
>>>>>
>>>>> Do you think there is enough in CEP
something fresh and start a [DISCUSS] Thread on that.Do you think there is enough in CEP-1 to keep moving with or is it completely wrong?PatrickOn Mon, Sep 30, 2024 at 4:53 PM Francisco Guerrero <fran...@apache.org> wrote:Hi folks,I feel I need to update the status of CEP-1 as it currently stands
; Thread on that.
>
> Do you think there is enough in CEP-1 to keep moving with or is it
> completely wrong?
>
> Patrick
>
> On Mon, Sep 30, 2024 at 4:53 PM Francisco Guerrero
> wrote:
>
> Hi folks,
>
> I feel I need to update the status of CEP-1 as it currently s
t;
>> Patrick
>>
>> On Mon, Sep 30, 2024 at 4:53 PM Francisco Guerrero
>> wrote:
>>> Hi folks,
>>>
>>> I feel I need to update the status of CEP-1 as it currently stands.
>>> For context, the Cassandra Sidecar project has had a steady flow of
4:53 PM Francisco Guerrero
> wrote:
>
>> Hi folks,
>>
>> I feel I need to update the status of CEP-1 as it currently stands.
>> For context, the Cassandra Sidecar project has had a steady flow of
>> contributions in the past couple of years. And there is a stea
Francisco Guerrero
wrote:
> Hi folks,
>
> I feel I need to update the status of CEP-1 as it currently stands.
> For context, the Cassandra Sidecar project has had a steady flow of
> contributions in the past couple of years. And there is a steady stream
> of upcoming contributions,
Hi folks,
I feel I need to update the status of CEP-1 as it currently stands.
For context, the Cassandra Sidecar project has had a steady flow of
contributions in the past couple of years. And there is a steady stream
of upcoming contributions, i.e live migration (CEP-40), CDC (CEP-44),
and many
43 matches
Mail list logo
