+1
On Wed, Apr 15, 2020, 6:58 AM Aleksey Yeshchenko
wrote:
> +1
>
> > On 15 Apr 2020, at 14:35, Oleksandr Petrov
> wrote:
> >
> > Hi everyone,
> >
> > Apache release rules were made for first-class projects. I would like to
> > propose simplifying voting rules for in-jvm-dtest-api project [1].
I think we're low volume enough across the board that we can continue
sidecar discussion on dev, and if we start to see too much noise, split
things up.
On Fri, Mar 13, 2020 at 1:46 PM Patrick McFadin wrote:
> I think Vinay just pinged everyone working on the project, but to Josh's
> point. is
Thanks for working on this, Mick. I think I'll have some time next week to
help out.
On Fri, Mar 13, 2020 at 5:38 AM Mick Semb Wever wrote:
>
> The ASF new Jenkins setup is almost complete.
> See https://ci-cassandra.apache.org/view/branches/
> The setup has been tracked in INFRA-19951
>
> The
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
I think there's more we can do to customize the circie setup, and am also a
hard -1 on disabling testing by default. We should figure out a way to opt
out of it, but the default should be on.
On Wed, Mar 25, 2020 at 7:51 AM Oleksandr Petrov
wrote:
> If you just want to disable them for your
Hey folks,
I was looking through our open JIRAs and realized we hadn't merged in
server side describe calls yet. The ticket died off a ways ago, and I
pinged Chris about it yesterday. He's got a lot of his plate and won't be
able to work on it anytime soon. I still think we should include this
ter than me.
> > > For now this strategy worked for me personally.
> > > Hope this helps
> > > Ekaterina
> > >
> > > Sent from my iPhone
> > >
> > > > On 1 Apr 2020, at 14:27, Jon Haddad wrote:
> > > >
> > > > Hey folk
I agree keeping the source separate is a good idea to start. If we find
some benefit later in merging the two trees, it's easy enough to do so,
it's more of a pain to split things apart.
The build system used plays a big part as well - ant is definitely not
doing us any favors here.
On Tue,
Separate JIRA is enough enough, separate dev list.. maybe. I don't see
much purpose in trying to organize into a hierarchy, what problem are you
actually solving here? It sounds like you don't trust folks who work on
the driver to not commit random code to Cassandra, is that the case? If
that's
and there's going to be
> significant work involved to go from the doc writing system these are
> authored in to Sphinx, or some other doc authoring system if we as a
> project decide to switch things. I know Jon Haddad has some opinions here
> and I think that'd be a great conv
assandra.html
> >.
> >
> > I've spoken with some of the doc writers and there's going to be
> > significant work involved to go from the doc writing system these are
> > authored in to Sphinx, or some other doc authoring system if we as a
> > project decide to swit
me to maintaining this going
> > forward.
> > > For those of you familiar, this is the DataStax sponsored / authored
> > > Cassandra documentation people often refer to in the community. Links
> can
> > > be found here
> > > <
> >
> https://docs.
Great idea Josh, +1
On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith
wrote:
> +1. This might also serve to produce specific points of discussion around
> the topic as the CEP progresses.
>
> Maybe put it high up the list, e.g. after Description of Approach?
>
>
>
> On 22/04/2020, 17:40,
;
> On Thu, Apr 30, 2020 at 5:02 AM John Sanda wrote:
>
> > +1 to asciidoc. My guess would be that more people are familiar with
> > markdown, but asciidoc definitely has more to offer and is easy enough to
> > use if you are familiar with markdown.
> >
> >
kup syntax seem
> reasonable. Whatever system ends up getting chosen, is there additional
> work that can be done to simplify work for writers? I've used all three
> (albeit not in-depth), so I'm willing to help.
>
> Derek
>
> On 5/1/20 11:08 AM, Jon Haddad wrote:
>
> >
+1, thanks Mick!
On Tue, Apr 14, 2020 at 8:49 AM Blake Eggleston
wrote:
> +1
>
> > On Apr 14, 2020, at 5:09 AM, e.dimitr...@gmail.com wrote:
> >
> > I also can’t see them. I think it matters to which interface is the
> link.
> >
> > And +1 from me, thanks!
> >
> >> On 14 Apr 2020, at 7:53,
t are more valuable than
> > >>>> CASSANDRA-14825,
> > >>>>> that are not included in 4.0?
> > >>>>> Where do we draw the line?
> > >>>>>
> > >>>>> I believe that if we were able to answer that question it would
>
ot being able to enforce
> a
> > >> > > standard can be confusing to the user because clues to using the
> > >> > > documentation lack consistency and refinement.
> > >> > >
> > >> > > In semantics-based documentation, such in
Thanks Mick,
-1 as well.
On Fri, Mar 20, 2020 at 11:39 AM Mick Semb Wever wrote:
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three
There's a lot going on here... hopefully I can respond to everything in a
coherent manner.
> Perhaps a simple way to avoid this is to update the random allocation
algorithm to re-generate tokens when the ranges created do not have a good
size distribution?
Instead of using random tokens for the
I don't think supporting only 3.6 not 3.7 was a deliberate move, it's
likely just an oversight. Yes, we should address that. Mind filing a
JIRA?
On Tue, Mar 24, 2020 at 11:33 AM Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:
> Hi,
>
> I built deb package for Debian from current
and pointing to that ticket)
> and
> it's used in a few places.
>
> Fwiw, it's this kind of things (and any future similar use we may want) I
> had
> in mind when discussing markdown being limited, and we can debate their
> importance, but we do use them.
>
> But maybe those don't qua
; >
> > Would it be possible to have a search bar somewhere on the site? I think
> > this would be useful to allow a user to navigate quickly to something
> they
> > know they are after e.g. a nodetool command or configuration setting.
> >
> > Kind regards,
>
I think coming up with a formal comprehensive guide for determining if we
can merge these sort of huge impacting features is a great idea.
I'm also on board with applying the same standard to the experimental
features.
On Wed, Jul 1, 2020 at 1:45 PM Joshua McKenzie wrote:
> Which questions and
I agree with Josh about it going on the downloads page - I don't think it's
appropriate. However, there is a community page that has things like books
& publications. I think it could be helpful to add a 3rd party projects
section to that page, as there's a number of useful utilities like
+1
On Fri, Jul 3, 2020 at 7:03 AM Brandon Williams wrote:
> +1
>
> On Fri, Jul 3, 2020, 4:57 AM Oleksandr Petrov
> wrote:
>
> > Proposing the test build of in-jvm dtest API 0.0.3 for release.
> >
> > Repository:
> >
> >
>
Support for Java 11 was added a long time ago, and it's been about 2 years
since it was released (Sept 2018). Had we released Cassandra 4 close to
that date, I'd be fine with keeping the status as experimental, but at this
point I'm wondering if releasing a new major version of C* that's
My goal here was to collect information, specifically around what people's
needs are and what people are testing. Some teams have a mandate they need
to move to Java 11, Python 3, etc. Some just want to take advantage of
features like low overhead heap profiling [1]. I don't have the visibility
Just wanted to note - a vote passes if there are 3 binding +1 and no -1's.
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
On Tue, Jul 14, 2020 at 3:47 PM Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.11.7 for release.
>
> sha1:
A couple days ago when writing a separate email I came across this DataStax
blog post discussing MVs [1]. Imagine my surprise when I noticed the date
was five years ago...
While at TLP, I helped numerous customers move off of MVs, mostly because
they affected stability of clusters in a horrific
gt; before a formal vote.
>
> I don't personally mind if we do that as a modification once this vote
> passes, or if we scrub the vote and try again.
>
>
> On 17/06/2020, 17:35, "Jon Haddad" wrote:
>
> > On the document I raised this as an issue, and propo
Jun 17, 2020 at 12:30 PM Jon Haddad wrote:
> >
> > > I'm not concerned today, no, just musing and pointing out that there
> are
> > easy ways to improve progress if we find there's an impediment. I don't
> > think it necessarily indicates bad intent to use voting rules
Looking at the doc again, I'm a bit concerned about this:
> PMC roll call will be taken every 6 months. This is an email to dev@
w/the simple question to pmc members of “are you active on the project and
plan to participate in voting over the next 6 months?”. This is strictly an
exercise to get
not count their vote at the roll call.
> The only real advantage of the roll call is that it's simple to administer.
>
> On 17/06/2020, 17:12, "Jon Haddad" wrote:
>
> Looking at the doc again, I'm a bit concerned about this:
>
> > PMC roll call
day vs. yesterday; one
>> day delay to clean this up now doesn't seem too much an imposition.
>>
>> @Jonathan Haddad - want to revise the wiki article
>> and call a new vote?
>>
>>
>> On Wed, Jun 17, 2020 at 2:13 PM Jon Haddad wrote:
>>
>>>
't really invalidate that decision, I
> think for forward progress it's better to simply address the vote floor,
> but just my 2c.
>
> On 17/06/2020, 21:58, "Jon Haddad" wrote:
>
> For what it's worth, I thought Benedict's suggestion was a pretty
> reasonable o
it has no recovery mechanism (whereas
> roll call at worst waits until the next roll call).
>
> Anyway, we had 11 votes on the rules, which would be 6 votes if we take
> 50%, and 7 if we take 66%. I think we'll be fine, whatever we do.
>
> On 18/06/2020, 19:48, "Jon Haddad"
ral votes in a
> row.
>
> On 18/06/2020, 18:58, "Joshua McKenzie" wrote:
>
> I'm formally stopping the vote. Jon, please revise the wiki.
>
> Good point about getting ourselves stuck into a corner we couldn't vote
> ourselves back out of. That'd just
t; > something that would be a non-issue assuming positive intent and
> alignment
> > between response to roll call and participation.
> >
> >
> > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai wrote:
> >
> >> +1 nb
> >>
We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch we'll
_also_ have whatever is next, let's call it 5.0.
Nothing is stopping us for discussing CEPs now, and nothing prevents folks
from making their own feature branches.
If we're going to add another branch (4.0) and let people
> I have been against the freeze from day one. In my opinion it had a
negative impact on the project.
I'm curious how you're measuring this. Based on my time as an evangelist
at DataStax and as a consultant with the Last Pickle, I can say I rarely
talked to people looking for shiny new features.
+1 (binding)
On Tue, Jun 16, 2020 at 9:32 AM Jeremiah D Jordan
wrote:
> +1 non-binding.
>
> Thanks for the work on this!
>
> > On Jun 16, 2020, at 11:31 AM, Jeff Jirsa wrote:
> >
> > +1 (pmc, binding)
> >
> >
> > On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie
> > wrote:
> >
> >> Added
+1 binding
On Sat, Jun 20, 2020, 11:24 AM Jordan West wrote:
> +1 (nb)
>
> On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis wrote:
>
> > +1
> >
> > On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie
> > wrote:
> >
> > > Link to doc:
> > >
> > >
> >
>
I think getting the CQL parser submitted upstream to pygments is a great
idea.
Anyone have experience with pygments?
On Mon, Jun 1, 2020 at 6:34 AM Mike Adamson wrote:
> The correct code location is:
>
> https://github.com/apache/cassandra/tree/trunk/doc/source/_util
>
> On Mon, 1 Jun 2020 at
> With regards to CEPs, I personally don't see any value in voting to start
one.
Agree with this, and I'd go even further - requiring a vote in order to
propose an idea runs so counter to the idea of a CEP that it would default
the purpose of even having them. The CEP is the _proposal_ for a
Agreed. This is an awesome POC in a pretty short period of time.
I suspect with a little polish and cleanup this will be an improvement over
the existing site in every way.
Thanks for putting this together, Lorina!
On Thu, Jun 11, 2020 at 7:36 AM Joshua McKenzie
wrote:
> Left bar navigation
-0
For the same reason as Benedict. I'd prefer we didn't deliberately violate
our own agreed on release rules just for the sake of some marketing blitz
that wasn't even publicly discussed but I won't stand in the way.
On Fri, Jul 17, 2020 at 9:27 AM Joshua McKenzie
wrote:
> >
> > I'm not
+1, thanks Mick for rerolling.
On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie
wrote:
> +1
>
> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote:
>
> > +1
> >
> > On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña <
> > a.penya.gar...@gmail.com>
> > wrote:
> >
> > > +1 (nb)
> > >
> > > On Mon,
I haven't looked at the patch, but at a high level, defaulting to direct I/O
for commit logs makes a lot of sense to me.
On 2023/10/16 06:34:05 "Pawar, Amit" wrote:
> [Public]
>
> Hi,
>
> CommitLog uses mmap (memory mapped ) segments by default. Direct-IO feature
> is proposed through new
e use of direct IO could well be of
> benefit eg in compaction - and also in future if we manage to bring a page
> management in process. So laying foundations there could be of benefit, even
> if the commit log eventually does not use it.
>
> > On 16 Oct 2023, at 17:00, Jon Haddad
I think this is a great more generally useful than the two scenarios you've
outlined. I think it could / should be possible to use an object store as the
primary storage for sstables and rely on local disk as a cache for reads.
I don't know the roadmap for TCM, but imo if it allowed for more
+1
On 2023/10/03 04:52:47 Mick Semb Wever wrote:
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>
> The SGA has been sent to the ASF. This does not require acknowledgement
> before the vote.
>
> Once
>From the folks I've been talking to - Accord is one of the biggest things to
>be excited about in 5.0. Everyone giving a presentation about the 5.0 release
>has been hyping up accord.
Shipping a release to make a date (that means practically nothing to most
people) by gutting one of the
I guess at the end of the day, shipping a release with a bunch of awesome
features is better than holding it back. If there's 2 big releases in 6 months
the community isn't any worse off.
We either ship something, or nothing, and something is probably better.
Jon
On 2023/10/24 16:27:04
+1 to removal of 8 in trunk.
On 2022/08/29 20:09:55 Blake Eggleston wrote:
> Hi all, I wanted to propose removing jdk8 support for 4.1. Active support
> ended back in March of this year, and I believe the community has built
> enough confidence in java 11 to make it an uncontroversial change
So much awesome here. Big +1 to having checkstyle be the source of truth.
On 2022/11/24 17:10:28 Maxim Muzafarov wrote:
> Hello everyone,
>
>
> First of all, thank you all for this awesome project which I have
> often been inspired by. My name is Maxim Muzafarov I'm a Committer and
> PMC of
I noticed nobody answered my actual question - what would it take for you to be
comfortable?
It seems that the need to do a release is now more important than the best
interests of the new user's experience - despite having plenty of *production*
experience showing that what we ship isn't
I'm curious what it would take for folks to be OK with merging this into 4.1?
How much additional time would you want to feel comfortable?
I should probably have been a little more vigorous in my +1 of Mick's PR. For
a little background - I worked on several hundred clusters while at TLP,
+1 to switching to G1.
No opinion about offheap objects.
On 2022/11/09 19:22:08 Mick Semb Wever wrote:
> Any objections to making these changes, at the very last minute, for
> 4.1-rc1 ?
> This is CASSANDRA-12029 and CASSANDRA-7486
>
> Provided we figure out patches for them in the next day
I like this suggestion and I'd take it a step further. I think the project
should be publishing docker images. If we manage to migrate to Gradle this
would be pretty trivial as the jib Gradle plugin is excellent and makes
creating and publishing Docker images really easy.
This sounds awesome. Could you share the fio configuration you used to
benchmark and what hardware you used?
On 2023/04/18 18:10:24 "Pawar, Amit" wrote:
> [Public]
>
> Hi,
>
> I shared my investigation about Commitlog I/O issue on large core count
> system in my previous email dated
Good suggestion Mike. I'm +1 on the idea and agree the name KEYSPACE is
confusing to new users.
Jon
On 2023/04/04 15:48:26 Mike Adamson wrote:
> Hi,
>
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
>
> Background: While TABLE was introduced as
+1
On 2023/02/06 16:15:19 Sam Tunnicliffe wrote:
> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
>
> Discussion:
>
+1
On 2023/06/13 14:14:35 Jeremy Hanna wrote:
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of the
> donation. Nothing more.
> The plan is to introduce the
Certain bits of functionality also already exist on the SASI side of things,
but I'm not sure how much overlap there is. Currently, there's a LIKE keyword
that handles token matching, although it seems to have some differences from
the feature set in SAI.
That said, there seems to be enough
duling solution in the sidecar, and there is nothing
> that would prevent someone from continuing to use a sidecar-based solution in
> perpetuity if they preferred.
>
> - Scott
>
> > On Jul 26, 2023, at 3:25 PM, Jon Haddad wrote:
> >
> > I'm 100% in favor of repair bei
Very nice! I'll kick the tires a bit, and add a sai test to tlp-stress
On 2023/07/26 18:56:29 Caleb Rackliffe wrote:
> Alright, the cep-7-sai branch is now merged to trunk!
>
> Now we move to addressing the most urgent items from "Phase 2" (
> CASSANDRA-18473
do not think LIKE actually applies here. LIKE is used for prefix,
> > contains, or suffix searches in SASI depending on the index type.
> >
> > This is about exact matching of tokens.
> >
> >> On Aug 2, 2023, at 5:53 PM, Jon Haddad wrote:
> >>
&g
>
> > > On Aug 2, 2023, at 7:18 PM, J. D. Jordan
> > wrote:
> > >
> > > I do not think LIKE actually applies here. LIKE is used for prefix,
> > contains, or suffix searches in SASI depending on the index type.
> > >
> > > This is about exa
I'm 100% in favor of repair being part of the core DB, not the sidecar. The
current (and past) state of things where running the DB correctly *requires*
running a separate process (either community maintained or official C* sidecar)
is incredibly painful for folks. The idea that your data
+1.
Awesome work Doug! Great to see this moving forward.
On 2023/05/04 18:34:46 "C. Scott Andreas" wrote:
> +1nb.As someone familiar with this work, it's pretty hard to overstate the
> impact it has on completing Cassandra's HTAP story. Eliminating the overhead
> of bulk reads and writes on
rs. CQL is already not the
> >>>> prettiest language, but let’s not make it a total mish mash.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 7 Aug 2023, at 10:59, Mike Adamson wrote:
> >>
point.
>
> > On Aug 13, 2023, at 12:53 PM, Jon Haddad wrote:
> >
> > Functions make sense to me too. In addition to the reasons listed, I if
> > we acknowledge that functions in predicates are inevitable, then it makes
> > total sense to use them here. I
outsmart the very
> complex system
>
> On Jan 18, 2024, at 4:56 PM, Jon Haddad wrote:
>
>
> I am definitely +1 on the ability to rate limit operations to tables and
> keyspaces, and if we can do it at a granular level per user I'm +1 to that
> as well. I think this
Stefan, can you elaborate on what you are proposing? It's not clear (at
least to me) what level of testing you're advocating for. Dropping testing
both on dev branches, every commit, just on release? In addition, can you
elaborate on what is a hassle about it? It's been a long time since I
Would it make sense to only block commits on the test strategy you've
listed, and shift the entire massive test suite to post-commit? If there
really is only a small % of times the entire suite is useful this seems
like it could unblock the dev cycle but still have the benefit of the full
test
Butler + the *jenkins-jira* integration script
>> <https://github.com/apache/cassandra-builds/blob/trunk/jenkins-jira-integration/jenkins_jira_integration.py>(need
>> to dust that off but it should remain good to go), we should have a pretty
>> clear view as to when any consiste
+1 to deprecating dual ports and removing in 5.0
On Tue, Feb 13, 2024 at 4:29 AM Štefan Miklošovič <
stefan.mikloso...@gmail.com> wrote:
> Alright ... so how I am interpreting this, even more so after Sam's and
> Brandon's mail, is that we should just get rid of that completely in trunk
> and
Sure, I’d love to work with you on this.
—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com
On Mon, Dec 18, 2023 at 8:30 AM Ariel Weisberg wrote:
> Hi,
>
> Thanks for the generous offer. Before you do that can you give me a chance
> to add back support for Caffeine for t
At a high level I really like the idea of being able to better leverage
cheaper storage especially object stores like S3.
One important thing though - I feel pretty strongly that there's a big,
deal breaking downside. Backups, disk failure policies, snapshots and
possibly repairs would get more
I think we should probably figure out how much value it actually provides
by getting some benchmarks around a few use cases along with some
profiling. tlp-stress has a --rowcache flag that I added a while back to
be able to do this exact test. I was looking for a use case to profile and
write up
I think it makes sense to see what the actual overhead is of CBO before
making the assumption it'll be so high that we need to have two code
paths. I'm happy to provide thorough benchmarking and analysis when it
reaches a testing phase.
I'm excited to see where this goes. I think it sounds very
., 11 gru 2023, 20:45 użytkownik Jon Haddad
> napisał:
>
>> Hey folks,
>>
>> Just wanted to raise awareness about a I/O issue that seems to be
>> affecting some Linux Kernal releases that were listed as STABLE, causing
>> corruption when using the ext4 filesys
Hey folks,
Just wanted to raise awareness about a I/O issue that seems to be affecting
some Linux Kernal releases that were listed as STABLE, causing corruption
when using the ext4 filesystem with direct I/O. I don't have time to get a
great understanding of the full scope of the issue, what
2024 at 4:11 PM Jon Haddad wrote:
> > Syntactically, if we’re updating settings like compaction throughput, I
> would prefer to simply update a virtual settings table
> > e.g. UPDATE system.settings SET compaction_throughput = 128
>
> I agree with this, sorry if that wa
gt; likely to check the documentation;
> - It will be easier for us to move the nodetool from the jmx client
> that is used under the hood to an implementation based on a
> java-driver and use the CQL for the same;
> - if we have cassandra-15254 merged, it will cost almost nothing to
> support the e
g with a cluster and configuring it
> justifies the investment for us as a project. Assuming someone has the
> cycles to, you know, actually do the work. :D
>
> On Sun, Jan 7, 2024, at 10:41 PM, Jon Haddad wrote:
>
> I like the idea of the ability to execute certain commands via CQ
Server side rate limiting can be useful, but imo if we were to focus effort
into a single place, time would be much better spent adding adaptive rate
limiting to the drivers.
Rate limiting at the driver level can be done based on 2 simple feedback
mechanisms - error rate and latency. When a node
I am definitely +1 on the ability to rate limit operations to tables and
keyspaces, and if we can do it at a granular level per user I'm +1 to that
as well. I think this would need to be exposed to the operator regardless
of any automatic rate limiter.
Thinking about the bigger picture for a
I like the idea of the ability to execute certain commands via CQL, but I
think it only makes sense for the nodetool commands that cause an action to
take place, such as compact or repair. We already have virtual tables, I
don't think we need another layer to run informational queries. I see
Count me in!
On 2023/12/05 14:34:48 Rich Bowen wrote:
> Hey, folks. I'll be at Cassandra Summit next week, and was wondering if any
> of you who might be there would be interested in doing a podcast interview
> with me for Voice Of Apache (the podcast formerly known as Feathercast - see
>
I like the idea of accepting more types of queries with fewer
restrictions. I think we've been moving in the right direction, with SAI
opening up more types of query possibilities.
I think the long term path towards more flexibility requires paying off
some technical debt. We have a ton of
This seems like a lot of work to create an rsync alternative. I can't
really say I see the point. I noticed your "rejected alternatives"
mentions it with this note:
- However, it might not be permitted by the administrator or available
in various environments such as Kubernetes or
Imo it would be better to have standalone JIRA projects for each of the
subprojects we have, just like we do the sidecar.
On Thu, Apr 4, 2024 at 10:47 AM Francisco Guerrero
wrote:
> Hi Bret,
>
> Thanks for bringing up this issue. The Cassandra Analytics library will
> also need to have its own
nage
>> and secure rsyncd processes on each instance if not via SSH.
>>
>> – An ecosystem-native approach is more instrumentable and measurable than
>> rsync. Support for data migration endpoints in the sidecar would allow for
>> metrics reporting, stats collection
+1
On Mon, Apr 15, 2024 at 7:49 AM Mick Semb Wever wrote:
>
>
>
>> Proposing the test build of Cassandra 3.0.30 for release.
>>
>
>
> +1
>
>
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds
> - binary artefact runs
> - debian package runs
> - debian repo
+1
On Mon, Apr 15, 2024 at 8:03 AM Mick Semb Wever wrote:
>
>
>
>> Proposing the test build of Cassandra 3.11.17 for release.
>
>
>
>
>
> +1
>
>
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds
> - binary artefact runs
> - debian package runs
> - debian repo
e.
>>
>> Alternatively, Cassandra itself could have some flag to start up with
>> limited
>> subsystems enabled to allow live migration.
>>
>> In any case, we'll need to weigh in the pros and cons of each alternative
>> and
>> decide if the live migrati
Jeff, this is probably the best explanation and justification of the idea
that I've heard so far.
I like it because
1) we really should have something official for backups
2) backups / object store would be great for analytics
3) it solves a much bigger problem than the single goal of moving
Hmm... I guess if you're using encryption you can't use ZCS so there's that.
It probably makes sense to implement kernel TLS:
https://www.kernel.org/doc/html/v5.7/networking/tls.html
Then we can get ZCS all the time, for bootstrap & replacements.
Jon
On Thu, Apr 18, 2024 at 12:50 PM
101 - 200 of 206 matches
Mail list logo
