>
> As I am on x86 and I wanted to simulate what would happen to users on ARM,
> I just did it other way around - I introduced the dependency with
> classifier linux-aarch_64.
>
> …
> Surprisingly, the installation step succeeded on x86 even the dependency
> was for aarch. However, the startup
Thank you everyone that was involved.
There's a lot to do with sub-projects, I'm sure the folk who will be
working with the drivers subproject will want to learn a lot from you.
On Fri, 21 Jul 2023 at 01:11, Yifan Cai wrote:
> Thank you for fixing the build on ci-cassandra! I am glad that I
On Fri, Jul 21, 2023 at 10:56 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
...
> I think this might work, if it is available, it will use it, if not, we
> emit a big fat warning.
>
...
I agree with this approach. It lets operators trap a log statement or
similar while defaulting
Thank you for fixing the build on ci-cassandra! I am glad that I can
contribute to the process :D
- Yifan
On Thu, Jul 20, 2023 at 4:00 PM Francisco Guerrero
wrote:
> Hi list,
>
> I wanted to bring some visibility into the Cassandra Sidecar CI health [1].
> It seems like it has been broken for
Hi list,
I wanted to bring some visibility into the Cassandra Sidecar CI health [1].
It seems like it has been broken for quite a while and we have finally fixed
it today.
Special thanks to Mick for noticing the issue and bringing it up to me. Also,
thanks to Yifan and Dinesh for reviewing the
Thank you all for your opinions. Very appreciated.
I finally got some time to play with the patch of Ayushi Singh.
As I am on x86 and I wanted to simulate what would happen to users on ARM, I
just did it other way around - I introduced the dependency with classifier
linux-aarch_64.
The whole
This feels analogous to other past discussions around prioritizing a config
that enables new users to clone + build + run as easily as possible, vs. having
better prod recommendations out of the box.
Both are important. I personally think we should default configuration to make
it just work
I think we could special-case and default to 'auto' but allow other
more explicit options.
Kind Regards,
Brandon
On Thu, Jul 20, 2023 at 4:18 PM German Eichberger via dev
wrote:
>
> In general I agree with Joey -- but I would prefer if this behavior is
> configurable, e.g. there is an option
In general I agree with Joey -- but I would prefer if this behavior is
configurable, e.g. there is an option to get a startup failure if the
configured fastest provider can't run for any reason to avoid a "silent"
performance degradation as Jordan was experiencing.
Thanks,
German
>
> 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 binding +1s and no -1's.
>
+1
Checked (in addition to Maxim's list)
- source artefact
Having native dependencies shouldn't make the project x86 only, it
should just accelerate the performance on x86 when available. Can't we
just try to load the fastest available provider (so arm will use
native java but x86 will use proper hardware acceleration) and failing
that fall-back to the
+1
> On Jul 18, 2023, at 11:28 PM, Miklosovic, Stefan
> wrote:
>
> Proposing the test build of Cassandra 4.1.3 for release.
>
> sha1: 2a4cd36475de3eb47207cd88d2d472b876c6816d
> Git: https://github.com/apache/cassandra/tree/4.1.3-tentative
> Maven Artifacts:
>
Maybe we could start providing Dockerfile’s and/or make arch specific rpm/deb
packages that have everything setup correctly per architecture?
We could also download them all and have the startup scripts put stuff in the
right places depending on the arch of the machine running them?
I feel like
+1 (nb)
Checked:
- the rc version
- the branch builds
- the branch version matches the rc version
- downloaded binaries and sources
- checksums and signature verified
I have created the following GitHub Action to automate the process:
Hi,
as I was reviewing the patch for this feature (1), we realized that it is not
quite easy to bundle this directly into Cassandra.
The problem is that this was supposed to be introduced as a new dependency:
software.amazon.cryptools
AmazonCorrettoCryptoProvider
2.2.0
15 matches
Mail list logo
