Add 'readonly' option to ob-sqlite

[Daniel M. German]

hi everybody,

Sometimes I think it is useful to open a DB in readonly mode

eg. to avoid modifying by mistake

This is a patch to ob-sqlite.el to accomplish that

It adds support for opening a sqlite database in readonly only.

It does it by adding a babel parameter readonly. If present, the
database will be opened in readonly mode. Example:

#+begin_src sqlite :readonly :db /tmp/rip.db
insert into a values (1,2);
select * from a;
#+end_src

This will result in the following error:

Runtime error near line 2: attempt to write a readonly database (8)
[ Babel evaluation exited with code 1 ]

>From 7df14e4ac2dcdc8fbdf647bff31c9e03f33bd73a Mon Sep 17 00:00:00 2001
From: Daniel M German 
Date: Thu, 6 Jun 2024 23:34:28 -0700
Subject: [PATCH] lisp/ob-sqlite.el: add a new parameter called readonly.

If present, the database is open in read-only mode.

This is implemented by passing the parameter -readonly to sqlite
---
 lisp/ob-sqlite.el | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 96d93b815..b15c4f4d3 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -52,7 +52,8 @@
 (line  . :any)
 (list  . :any)
 (separator . :any)
-(nullvalue . :any))
+(nullvalue . :any)
+(readonly  . :any))
   "Sqlite specific header args.")
 
 (defun org-babel-expand-body:sqlite (body params)
@@ -77,10 +78,10 @@ This function is called by `org-babel-execute-src-block'."
 	(separator (cdr (assq :separator params)))
 	(nullvalue (cdr (assq :nullvalue params)))
 	(headers-p (equal "yes" (cdr (assq :colnames params
-	(others (delq nil (mapcar
+(others (delq nil (mapcar
 			   (lambda (arg) (car (assq arg params)))
 			   (list :header :echo :bail :column
- :csv :html :line :list)
+ :csv :html :line :list :readonly)
 (with-temp-buffer
   (insert
(org-babel-eval
@@ -88,7 +89,7 @@ This function is called by `org-babel-execute-src-block'."
 	 "%cmd %header %separator %nullvalue %others %csv %db "
 	 (list
 	  (cons "cmd" org-babel-sqlite3-command)
-	  (cons "header" (if headers-p "-header" "-noheader"))
+  (cons "header" (if headers-p "-header" "-noheader"))
 	  (cons "separator"
 		(if separator (format "-separator %s" separator) ""))
 	  (cons "nullvalue"
-- 
2.45.1




--
Daniel M. German  "A machine --computer-- can only do
   Lady Lovelace ->what we tell it to do"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Re: kvm crash with virtiofs

[German Maglione]

On Thu, Jun 6, 2024 at 10:40 AM Miklos Szeredi  wrote:
>
> Hi,
>
> I get the below crash when running virtio-fs on fedora 39.
>
> Note: weirdly this makes chrome running on the host also crash.
>
> Eric Sandeen also reported some bad behavior of virtio-fs on fc39,
> which might be related.
>
> Versions:
> kernel-6.8.4-200.fc39.x86_64
> qemu-kvm-8.1.3-5.fc39.x86_64
> virtiofsd-1.10.1-1.fc39.x86_64
>
> Thanks,
> Miklos
>
> /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu --shared-dir /home &
>
> qemu-system-x86_64 -enable-kvm -s -serial none -parallel none -kernel
> /home/mszeredi/git/linux/arch/x86_64/boot/bzImage -drive
> format=raw,file=/home/mszeredi/root_fs,index=0,if=virtio -drive
> format=raw,file=/home/mszeredi/images/ubd1,index=1,if=virtio -chardev
> stdio,id=virtiocon0,signal=off -device virtio-serial -device
> virtconsole,chardev=virtiocon0 -cpu host -m 16G -smp 8 -object
> memory-backend-file,id=mem,size=16G,mem-path=/dev/shm,share=on -numa
> node,memdev=mem -net user -net nic,model=virtio-net-pci -fsdev
> local,security_model=none,id=fsdev0,path=/home -device virtio-rng-pci
> -chardev socket,id=char0,path=/tmp/vhostqemu -device
> vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs -device
> virtio-9p-pci,fsdev=fsdev0,mount_tag=hostshare -append "root=/dev/vda
> console=hvc0 "

are you running virtiofsd inside a container?, could you try

-object memory-backend-memfd,id=mem,size=16G,share=on

instead of "-object memory-backend-file..."

> [...]
> root@kvm:~# time md5sum /host/mszeredi/images/ubd1
> error: kvm run failed Bad address
> RAX= RBX=888100044240 RCX=
> RDX=888420c59ff0
> RSI=0020 RDI=888420c59ff8 RBP=
> RSP=c900016d3898
> R8 =888420c59da8 R9 =0040 R10=00036140
> R11=0005
> R12=888420c59ff0 R13=000d R14=ea0010831600
> R15=888420c59da8
> RIP=82168d80 RFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =   00c0
> CS =0010   00a09b00 DPL=0 CS64 [-RA]
> SS =0018   00c09300 DPL=0 DS   [-WA]
> DS =   00c0
> FS = 7fb83cea8740  00c0
> GS = 88842fd4  00c0
> LDT=   00c0
> TR =0040 fe12a000 4087 8b00 DPL=0 TSS64-busy
> GDT= fe128000 007f
> IDT= fe00 0fff
> CR0=80050033 CR2=7f2d3bd9b0f0 CR3=0001036ee005 CR4=00770ef0
> DR0= DR1= DR2=
> DR3=
> DR6=0ff0 DR7=0400
> EFER=0d01
> Code=90 90 90 90 48 c7 07 00 00 00 00 48 89 fa 48 8d 7f 08 31 c0 <48>
> c7 87 30 02 00 00 00 00 00 00 48 89 d1 48 83 e7 f8 48 29 f9 81 c1 40
> 02 00 00 c1 e9 03
>
>


-- 
German

Re: [EXTERNAL] Re: [DISCUSS] Adding experimental vtables and rules around them

[German Eichberger via dev]

Hi,

To sum where everyone is coming from: We would like to have features in a 
stable version of Cassandra which are experimental and are subject to 
non-backward compatible change. This indicates to me that the feature is not 
finished and should likely not be included in a stable release.  What benefit 
are we looking for by including it into a stable release as opposed to rolling 
it to the next release.

Thanks,
German

From: Maxim Muzafarov 
Sent: Wednesday, May 29, 2024 1:09 PM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] Adding experimental vtables and rules around 
them

Hello everyone,

I like the idea of highlighting some of the experimental virtual
tables whose model might be changed in future releases.

As another option, we could add an @Experimetal annotation (or another
name) and a configuration parameter
experimental_virtula_tables_enabled (default is false). This, in turn,
means if a virtual table is experimental, it won't be registered in a
virtual keyspace unless the corresponding configuration parameter is
enabled. This also means that a user must implicitly enable an
experimental API, and prevent us from spamming the log with warnings.
All of this does not preclude us from specifying the experimental
state of some virtual tables in the documentation.

On Wed, 29 May 2024 at 21:18, Abe Ratnofsky  wrote:
>
> I agree that ClientWarning is the best way to indicate the risk of using an 
> experimental feature directly to the user. Presenting information in the 
> client application's logs directly means that the person who wrote the query 
> is most likely to see the warning, rather than an operator who sees cluster 
> logs.
>
> I don't think it's necessary to attach a ClientWarning to every single client 
> response; a ClientWarning analog to NoSpamLogger would be useful for this 
> ("warn a client at most once per day").
>
> This would also be useful for warning on usage of deprecated features.
>
> > On May 29, 2024, at 3:01 PM, David Capwell  wrote:
> >
> > We agreed a long time ago that all new features are disabled by default, 
> > but I wanted to try to flesh out what we “should” do with something that 
> > might still be experimental and subject to breaking changes; I would prefer 
> > we keep this thread specific to vtables as the UX is different for 
> > different types of things…
> >
> > So, lets say we are adding a set of vtables but we are not 100% sure what 
> > the schema should be and we learn after the release that changes should be 
> > made, but that would end up breaking the table… we currently define 
> > everything as “don’t break this” so if we publish a table that isn’t 100% 
> > baked we are kinda stuck with it for a very very long time… I would like to 
> > define a way to expose vtables that are subject to change (breaking schema 
> > changes) across different release and rules around them (only in minor?  
> > Maybe even in patch?).
> >
> > Lets try to use a concrete example so everyone is on the same page.
> >
> > Accord is disabled by default (it is a new feature), so the vtables to 
> > expose internals would be expected to be undefined and not present on the 
> > instance.
> >
> > When accord is enabled (accord.enabled = true) we add a set of vtables:
> >
> > Epochs - shows what epochs are known to accord
> > Cache - shows how the internal caches are performing
> > Etc.
> >
> > Using epochs as an example it currently only shows a single column: the 
> > long epoch
> >
> > CREATE VIRTUAL TABLE system_accord.epochs (epoch bigint PRIMARY KEY);
> >
> > Lets say we find that this table isn’t enough and we really need to scope 
> > it to each of the “stores” (threads for processing accord tasks)
> >
> > CREATE VIRTUAL TABLE system_accord.epochs (epoch bigint, store_id int, 
> > PRIMARY KEY (epoch, store_id));
> >
> > In this example the table changed the schema in a way that could break 
> > users, so this normally is not allowed.
> >
> > Since we don’t really have a way to define something experimental other 
> > than NEWS.txt, we kinda get stuck with this table and are forced to make 
> > new versions and maintain them for a long time (in this example we would 
> > have epochs and epochs_v2)… it would be nice if we could define a way to 
> > express that tables are free to be changed (modified or even deleted) and 
> > the life cycle for them….
> >
> > I propose that we allow such a case and make changes to the UX (as best as 
> > we can) to warn about this:
> >
> > 1) update NEWS.txt to denote that the feature is experimental
> > 2) when you access an experimental table you get a ClientWarning stating 
> > that this is free to change
> > 3) the tables comments starts with “[EXPERIMENTAL]”
> >
> > What do others think?
> >
> >
>

Re: [FFmpeg-user] Low FPS with H.264 Encoding When Using -pix_fmt yuv420p

[German Geraskin]

>
> Hello,
> when I use the following command in Raspberry Pi 4 model B, I am getting
> only 8 fps for 1080p resolution.
>
> *ffmpeg -use_wallclock_as_timestamps 1 -t 60 -i /dev/video0 -c:v
> h264_v4l2m2m -b:v 8M -maxrate 2M -vsync 2 -bufsize 4M -r 30 -s hd1080
> -pix_fmt yuv420p -g 30 -qmin 20 -qmax 50 output_1080p.mp4*
>
> And when I use the same command, but remove -pix_fmt yuv420p, the output
> video is 27 fps.
>
>
> *ffmpeg -use_wallclock_as_timestamps 1 -t 60 -i /dev/video0 -c:v
> h264_v4l2m2m -b:v 8M -maxrate 2M -vsync 2 -bufsize 4M -r 30 -s hd1080  -g
> 30 -qmin 20 -qmax 50 output1_1080p.mp4*
> Why does the fps reduce when -pix_fmt yuv420p is used in the ffmpeg command?
> Both the output videos have pixel format of YUV420, but when I use
> '-pix_fmt yuv420p' in command, why does it reduce the fps ?
> What are the default settings to tune the Encoding ?

Have you checked what pixel format is default for the input device
(/dev/video0)?

Based on your description, I can suppose that YUV420 is the default
format of the input device.
When you do not use -pix_fmt, the pixels are just transferred from
input device to encoder as is.
When you use -pix_fmt, the pixels are transferred to a pixel
transformation algorithm first,
and then converted pixels are transferred to the encoder.
So your machine spends the processor's time converting pixels from
YUV420 to YUV420.
For Raspberry Pi this could be not an easy task. (I heard that ffmpeg
is too heavy RPi).

I am not an expert neither in ffmpeg implementation nor in RPi
architecture, so above is only my technical intuition.

Have a great day :)
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

[German Eichberger via dev]

Thanks for the proposal. I second Jordan that we need more abstraction in (1), 
e.g. most cloud provider allow for disk snapshots and starting nodes from a 
snapshot which would be a good mechanism if you find yourself there.

German

From: Jordan West 
Sent: Sunday, April 14, 2024 12:27 PM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar 
for Live Migrating Instances

Thanks for proposing this CEP! We have something like this internally so I have 
some familiarity with the approach and the challenges. After reading the CEP a 
couple things come to mind:

1. I would like to see more abstraction of how the files get moved / put in 
place with the proposed solution being the default implementation. That would 
allow others to plug in alternatives means of data movement like pulling down 
backups from S3 or rsync, etc.

2. I do agree with Jon’s last email that the lifecycle / orchestration portion 
is the more challenging aspect. It would be nice to address that as well so we 
don’t end up with something like repair where the building blocks are there but 
the hard parts are left to the operator. I do, however, see that portion being 
done in a follow-on CEP to limit the scope of CEP-40 and have a higher chance 
for success by incrementally adding these features.

Jordan

On Thu, Apr 11, 2024 at 12:31 Jon Haddad 
mailto:j...@jonhaddad.com>> wrote:
First off, let me apologize for my initial reply, it came off harsher than I 
had intended.

I know I didn't say it initially, but I like the idea of making it easier to 
replace a node.  I think it's probably not obvious to folks that you can use 
rsync (with stunnel, or alternatively rclone), and for a lot of teams it's 
intimidating to do so.  Whether it actually is easy or not to do with rsync is 
irrelevant.  Having tooling that does it right is better than duct taping 
things together.

So with that said, if you're looking to get feedback on how to make the CEP 
more generally useful, I have a couple thoughts.

> Managing the Cassandra processes like bringing them up or down while 
> migrating the instances.

Maybe I missed this, but I thought we already had support for managing the C* 
lifecycle with the sidecar?  Maybe I'm misremembering.  It seems to me that 
adding the ability to make this entire workflow self managed would be the 
biggest win, because having a live migrate *feature* instead of what's 
essentially a runbook would be far more useful.

> To verify whether the desired file set matches with source, only file path 
> and size is considered at the moment. Strict binary level verification is 
> deferred for later.

Scott already mentioned this is a problem and I agree, we cannot simply rely on 
file path and size.

TL;DR: I like the intention of the CEP.  I think it would be better if it 
managed the entire lifecycle of the migration, but you might not have an 
appetite to implement all that.

Jon


On Thu, Apr 11, 2024 at 10:01 AM Venkata Hari Krishna Nukala 
mailto:n.v.harikrishna.apa...@gmail.com>> 
wrote:
Thanks Jon & Scott for taking time to go through this CEP and providing inputs.

I am completely with what Scott had mentioned earlier (I would have added more 
details into the CEP). Adding a few more points to the same.

Having a solution with Sidecar can make the migration easy without depending on 
rsync. At least in the cases I have seen, rsync is not enabled by default and 
most of them want to run OS/images with as minimal requirements as possible. 
Installing rsync requires admin privileges and syncing data is a manual 
operation. If an API is provided with Sidecar, then tooling can be built around 
it reducing the scope for manual errors.

From performance wise, at least in the cases I had seen, the File Streaming API 
in Sidecar performs a lot better. To give an idea on the performance, I would 
like to quote "up to 7 Gbps/instance writes (depending on hardware)" from 
CEP-28 as this CEP proposes to leverage the same.

For:

>When enabled for LCS, single sstable uplevel will mutate only the level of an 
>SSTable in its stats metadata component, which wouldn't alter the filename and 
>may not alter the length of the stats metadata component. A change to the 
>level of an SSTable on the source via single sstable uplevel may not be caught 
>by a digest based only on filename and length.

In this case file size may not change, but the timestamp of last modified time 
would change, right? It is addressed in section MIGRATING ONE INSTANCE, point 
2.b.ii which says "If a file is present at the destination but did not match 
(by size or timestamp) with the source file, then local file is deleted and 
added to list of files to download.". And after download by final data copy 
task, file should match with source.

On Thu, Apr 11, 2024 at 7:30 AM C. Scott Andreas 
mailto:sc...@parad

Re: [DISCUSS] NULL handling and the unfrozen collection issue

[German Eichberger via dev]

Hi,

+1 I like doing it the SQL way. This makes sense to me.

Now, in Cassandra setting a column to null means deleting it and if all​ 
columns in a row are null the row is deleted. This might be another edge case...

German

From: Benjamin Lerer 
Sent: Wednesday, March 20, 2024 9:15 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] [DISCUSS] NULL handling and the unfrozen collection issue

You don't often get email from b.le...@gmail.com. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Hi everybody,

CEP-29 (CQL NOT Operator) is hitting the grey area of how we want as a 
community to handle NULL including for things like unfrozen (multi-cell) 
collections and I would like to make a proposal for moving forward with NULL 
related issues.

We have currently 2 tickets open about NULL handling (I might have missed 
others):

  1.  CASSANDRA-10715<https://issues.apache.org/jira/browse/CASSANDRA-10715>: 
Allowing Filtering on NULL
  2.  CASSANDRA-17762<https://issues.apache.org/jira/browse/CASSANDRA-17762>: 
LWT IF col = NULL is inconsistent with SQL NULL

We also had previously some discussion on which we touched the subject:

  *   [DISCUSS] LWT UPDATE semantics with + and - when null
  *   CEP-15 multi key transaction syntax

In all those tickets and discussions the consensus was to have a behavior 
similar to SQL.

For null comparisons, SQL uses the three-value logic 
(https://modern-sql.com/concept/three-valued-logic) introducing the need for IS 
NULL and IS NOT NULL operators. Those conflict with the col = NULL predicate 
supported in LWT conditions 
(CASSANDRA-17762<https://issues.apache.org/jira/browse/CASSANDRA-17762>).

So far, as Cassandra was only using inclusive operators, comparisons were 
behaving in an expected way. According to three-valued logic NULL CONTAINS 
'foo' should return UNKNOWN and the filtering behavior should exclude 
everything which is not true.Therefore the row should not be returned as 
expected. With exclusive operators things are more tricky. NULL NOT CONTAINS 
'foo' will also return UNKNOWN causing the row to not be returned which might 
not match people's expectations.
This behavior can be even more confusing once you take into account empty and 
null collections. NOT CONTAINS on an empty collection will return true while it 
will return UNKNOWN on a NULL collection. Unfortunately, for unfrozen 
(multicell) collections we are unable to differentiate between an empty and 
null collection and therefore always treat empty collections as NULL.
For predicates such as map[myKey] != 'foo' when myKey is not present the result 
can also be surprising as it will end up comparing NULL to 'foo' returning once 
more UNKNOWN and ignoring the row.
In order to respect the SQL three-valued logic and be able to allow the user to 
fetch all the rows which do not contains a specific value we would need support 
IS NULL, IS NOT NULL and OR to allow query like:
WHERE c IS NULL OR c NOT CONTAINS 'foo' / WHERE m IS NULL OR m[myKey] != foo

Supporting the three-valued logic makes sense to me even if some behavior might 
end up being confusing. In which case we can easily fix CASSANDRA-10715 and 
deprectate support for col = NULL/col != NULL in LWT.

What is people's opinion? Should we go for the three-valued logic everywhere? 
Should we try something else?

Call for Papers now open: Azure Cosmos DB Conf 2024

[German Eichberger via user]

All,

I got clarification that they are also interested in Cassandra 5.0 and Vector 
Search - ideally using Azure Managed Instances for Apache Cassandra 

In any case here is the link: 
https://devblogs.microsoft.com/cosmosdb/call-for-papers-now-open-azure-cosmos-db-conf-2024/
 and submissions are due February 15, 2024
[https://www.bing.com/th?id=OVP.BEm3BNnfcIoSTUqJVdzipgHgFo=Api]<https://devblogs.microsoft.com/cosmosdb/call-for-papers-now-open-azure-cosmos-db-conf-2024/>
Call for Papers now open: Azure Cosmos DB Conf 
2024<https://devblogs.microsoft.com/cosmosdb/call-for-papers-now-open-azure-cosmos-db-conf-2024/>
We are thrilled to announce that the Call for Papers (CFP) for the Azure Cosmos 
DB Conf 2024 is now officially open! This is an exciting opportunity for you to 
share your knowledge, experiences, and innovations with a vibrant and diverse 
community of developers.
devblogs.microsoft.com

Thanks,
German

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

[German Eichberger via dev]

Jaydeep,

I concur with Stefan that extensibility of this  should be a design goal:

  *   It should be easy to add additional metrics (e.g. write queue depth) and 
decision logic
  *   There should be a way to interact with other systems to signal a resource 
need  which then could kick off things like scaling

Super interested in this and we have been thinking about siimilar things 
internally 

Thanks,
German

From: Jaydeep Chovatia 
Sent: Tuesday, January 16, 2024 1:16 PM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

You don't often get email from chovatia.jayd...@gmail.com. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Hi Stefan,

Please find my response below:
1) Currently, I am keeping the signals as interface, so one can override with a 
different implementation, but a point noted that even the interface APIs could 
be also made dynamic so one can define APIs and its implementation, if they 
wish to override.
2) I've not looked into that yet, but I will look into it and see if it can be 
easily integrated into the Guardrails framework.
3) On the server side, when the framework detects that a node is overloaded, 
then it will throw OverloadedException back to the client. Because if the node 
while busy continues to serve additional requests, then it will slow down other 
peer nodes due to dependencies on meeting the QUORUM, etc. In this, we are at 
least preventing server nodes from melting down, and giving the control to the 
client via OverloadedException. Now, it will be up to the client policy, if 
client wishes to retry immediately on a different server node then eventually 
that server node might be impacted, but if client wishes to do exponential back 
off or throw exception back to the application then that server node will not 
be impacted.


Jaydeep

On Tue, Jan 16, 2024 at 10:03 AM Štefan Miklošovič 
mailto:stefan.mikloso...@gmail.com>> wrote:
Hi Jaydeep,

That seems quite interesting. Couple points though:

1) It would be nice if there is a way to "subscribe" to decisions your 
detection framework comes up with. Integration with e.g. diagnostics subsystem 
would be beneficial. This should be pluggable - just coding up an interface to 
dump / react on the decisions how I want. This might also act as a notifier to 
other systems, e-mail, slack channels ...

2) Have you tried to incorporate this with the Guardrails framework? I think 
that if something is detected to be throttled or rejected (e.g writing to a 
table), there might be a guardrail which would be triggered dynamically in 
runtime. Guardrails are useful as such but here we might reuse them so we do 
not need to code it twice.

3) I am curious how complex this detection framework would be, it can be 
complicated pretty fast I guess. What would be desirable is to act on it in 
such a way that you will not put that node under even more pressure. In other 
words, your detection system should work in such a way that there will not be 
any "doom loop" whereby mere throttling of various parts of Cassandra you make 
it even worse for other nodes in the cluster. For example, if a particular node 
starts to be overwhelmed and you detect this and requests start to be rejected, 
is it not possible that Java driver would start to see this node as "erroneous" 
with delayed response time etc and it would start to prefer other nodes in the 
cluster when deciding what node to contact for query coordination? So you would 
put more load on other nodes, making them more susceptible to be throttled as 
well ...

Regards

Stefan Miklosovic

On Tue, Jan 16, 2024 at 6:41 PM Jaydeep Chovatia 
mailto:chovatia.jayd...@gmail.com>> wrote:
Hi,

Happy New Year!

I would like to discuss the following idea:

Open-source Cassandra 
(CASSANDRA-15013<https://issues.apache.org/jira/browse/CASSANDRA-15013>) has an 
elementary built-in memory rate limiter based on the incoming payload from user 
requests. This rate limiter activates if any incoming user request’s payload 
exceeds certain thresholds. However, the existing rate limiter only solves 
limited-scope issues. Cassandra's server-side meltdown due to overload is a 
known problem. Often we see that a couple of busy nodes take down the entire 
Cassandra ring due to the ripple effect. The following document proposes a 
generic purpose comprehensive rate limiter that works considering system 
signals, such as CPU, and internal signals, such as thread pools. The rate 
limiter will have knobs to filter out internal traffic, system traffic, 
replication traffic, and furthermore based on the types of queries.

More design details to this doc: [OSS] Cassandra Generic Purpose Rate Limiter - 
Google 
Docs<https://docs.google.com/document/d/1w-A3fnoeBS6tS1ffBda_R0QR90olzFoMqLE7znFEUrQ/edit>

Please let me know your thoughts.

Jaydeep

Re: Welcome Maxim Muzafarov as Cassandra Committer

[German Eichberger via dev]

Congrats!!

From: David Capwell 
Sent: Monday, January 8, 2024 11:03 AM
To: dev 
Subject: [EXTERNAL] Re: Welcome Maxim Muzafarov as Cassandra Committer

Congrats!

On Jan 8, 2024, at 10:53 AM, Jacek Lewandowski  
wrote:

Congratulations Maxim, well deserved, it's a pleasure to work with you!

- - -- --- -  -
Jacek Lewandowski


pon., 8 sty 2024 o 19:35 Lorina Poland 
mailto:polan...@apache.org>> napisał(a):
Congratulations Maxim!

On 2024/01/08 18:19:04 Josh McKenzie wrote:
> The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov has 
> accepted
> the invitation to become a committer.
>
> Thanks for all the hard work and collaboration on the project thus far, and 
> we're all looking forward to working more with you in the future. 
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>
>

[USRP-users] Re: CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design contains one or more evaluation cores that will cease to function after a certain period of time. This desig

[German Farinas]

Ok, thanks for the clarification.

German

On Fri, Dec 22, 2023, 4:55 PM Wade Fife  wrote:

> Hi German,
>
> The critical warning sounds ominous but can be safely ignored. The
> licenses are included with Vivado, but Vivado gives the warning anyway. As
> long as you have a Vivado license, and a bitstream was generated, the 10
> GbE IP should work fine.
>
> Wade
>
> On Thu, Dec 21, 2023 at 11:20 AM German Farinas 
> wrote:
>
>> Update on this. Looking at the build log I found this:
>>
>> Evaluation cores found in this design:
>> IP core 'ten_gig_eth_pcs_pma' (ten_gig_eth_pcs_pma_v6_0_19) was
>> generated using a design_linking license.
>>
>> Resolution: If a new IP Core license was added, in order for the new
>> license to be picked up, the current netlist needs to be updated by
>> resetting and re-generating the IP output products before bitstream
>> generation.
>>
>> How do I regenerate the IP core?
>>
>> Best,
>> German
>>
>> On Wed, Dec 20, 2023 at 10:48 PM German Farinas 
>> wrote:
>>
>>> Hello,
>>>
>>> I ran the example in this guide (
>>> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0) to add a
>>> new FFT RFNoC block. I modify the default yaml file and run the following
>>> command:
>>>
>>> rfnoc_image_builder -y x300_with_fft.yml -t X300_HG -F ../../../
>>>
>>> Everything went well and the bitstream file was successfully generated.
>>> I uploaded to my USRP X300 with the following command: uhd_image_loader
>>> --args "type=x300,addr=192.168.10.2" --fpga-path
>>> ./build/usrp_x300_fpga_HG.bin
>>>
>>> after loading the new image this is the output to the *uhd_usrp_probe
>>> --args type=x300* command:
>>>
>>> RFNoC blocks on this device:
>>> |   |
>>> |   |   * 0/DDC#0
>>> |   |   * 0/DDC#1
>>> |   |   * 0/DUC#0
>>> |   |   * 0/DUC#1
>>> |   |   * 0/FFT#0
>>> |   |   * 0/Radio#0
>>> |   |   * 0/Radio#1
>>> |   |   * 0/Replay#0
>>> | _
>>> |/
>>> |   |   Static connections on this device:
>>> |   |
>>> |   |   * 0/SEP#0:0==>0/DUC#0:0
>>> |   |   * 0/DUC#0:0==>0/Radio#0:0
>>> |   |   * 0/Radio#0:0==>0/DDC#0:0
>>> |   |   * 0/DDC#0:0==>0/SEP#0:0
>>> |   |   * 0/Radio#0:1==>0/DDC#0:1
>>> |   |   * 0/DDC#0:1==>0/SEP#1:0
>>> |   |   * 0/SEP#2:0==>0/DUC#1:0
>>> |   |   * 0/DUC#1:0==>0/Radio#1:0
>>> |   |   * 0/Radio#1:0==>0/DDC#1:0
>>> |   |   * 0/DDC#1:0==>0/SEP#2:0
>>> |   |   * 0/Radio#1:1==>0/DDC#1:1
>>> |   |   * 0/DDC#1:1==>0/SEP#3:0
>>> |   |   * 0/SEP#4:0==>0/Replay#0:0
>>> |   |   * 0/Replay#0:0==>0/SEP#4:0
>>> |   |   * 0/SEP#5:0==>0/Replay#0:1
>>> |   |   * 0/Replay#0:1==>0/SEP#5:0
>>> |   |   * 0/SEP#6:0==>0/FFT#0:0
>>> |   |   * 0/FFT#0:0==>0/SEP#6:0
>>>
>>> Everything apparently looks good because the FFT was inserted. However
>>> during the last phase of the vivado tools flow, after synthesis, place,
>>> route, etc, during the *BUILDER: Writing bitfile *phase it issues the
>>> following supposedly critical warning:
>>>
>>> *CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This
>>> design contains one or more evaluation cores that will cease to function
>>> after a certain period of time. This design should NOT be used in
>>> production systems.*
>>>
>>> I think it may be the FFT IP core but I am not sure. I have Vivado
>>> v2021.1_AR76780 ML with an Enterprise Edition license. The version is 2021
>>> because this is the version supported by Ettus for building FPGA images. My
>>> license goes up to 2023.1 limit, but this should not affect me because I am
>>> using the 2021 version. I compiled the default images and I don't recall
>>> receiving this critical warning.
>>>
>>> Anyone had the same issue? Any help or explanation to this? Is this
>>> something I should worry about ?
>>>
>>> Best regards,
>>> German
>>>
>>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

[German Eichberger via dev]

+1

From: Patrick McFadin 
Sent: Friday, December 22, 2023 9:12 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: Harry in-tree (Forked from "Long tests, Burn tests, 
Simulator tests, Fuzz tests - can we clarify the diffs?")

It was great having some more extended discussions about Harry in person last 
week. Anything we can do to make it easier for anyone to test Cassandra 
thoroughly is an easy +1 from me!

Thanks for all your efforts so far, Alex.

Patrick

On Fri, Dec 22, 2023 at 8:03 AM Jacek Lewandowski 
mailto:lewandowski.ja...@gmail.com>> wrote:
Obviously +1

Thank you Alex

pt., 22 gru 2023, 16:45 użytkownik Sumanth Pasupuleti 
mailto:sumanth.pasupuleti...@gmail.com>> 
napisał:
+1, thank you for your efforts in bringing Harry in-tree. Anything that 
improves the testing ecosystem for Cassandra, particularly around complex 
scenarios / edge cases  goes a long way in improving reliability, and with 
having a powerful tool like Harry in-tree, it is a lot more accessible to the 
developers than it has been. Also, thank you for keeping in mind the onboarding 
experience of developers.

- Sumanth

On Fri, Dec 22, 2023 at 1:11 AM Alex Petrov 
mailto:al...@coffeenco.de>> wrote:
Some follow-up tickets to establish the project direction:

https://issues.apache.org/jira/browse/CASSANDRA-19229

Two other things that we will work on in Tree are:
https://issues.apache.org/jira/browse/CASSANDRA-18275 (model and in-JVM test 
for partition-restricted 2i queries)
https://issues.apache.org/jira/browse/CASSANDRA-18667 (multi-threaded SAI read 
and write fuzz test)

If you would like to get your recently added feature tested with Harry model, 
please let me know!

On Fri, Dec 22, 2023, at 12:41 AM, Joseph Lynch wrote:
+1

Sounds like a great change that will help us unify around a common testing 
paradigm, and even pave the path to in-tree load testing plus integrated 
correctness checking which would be extremely valuable!

-Joey

On Thu, Dec 21, 2023 at 1:35 PM Caleb Rackliffe 
mailto:calebrackli...@gmail.com>> wrote:
+1

Agree w/ all the justifications mentioned above.

As a reviewer on 
CASSANDRA-19210, my 
goals were to a.) look at the directory, naming, and package structure of the 
ported code, b.) make sure IDE integration was working, and c.) make sure any 
modifications to existing code (rather than direct code movements from 
cassandra-harry) were straightforward.

On Thu, Dec 21, 2023 at 3:23 PM Alex Petrov 
mailto:al...@coffeenco.de>> wrote:

Hey folks,

I am mostly done with a patch that brings Harry in-tree [1]. I will trigger one 
more CI run overnight, and my intention was to merge it some time soon, but I 
wanted to give a fair warning here, since this is a relatively large patch.

Good news for everyone that it:
  a) touches no production code whatsoever. Only test (in-jvm dtest namely) 
code that was using Harry already.
  b) the only tests that are changed are ones that used a duplicate version of 
placement simulator we had both for testing TCM, and in Harry
  c) in addition, I have converted 3 existing TCM tests to a new API to have 
some base for examples/usage.

Since we were effectively relying on this code for a while now, and the 
intention now is to converge to:
  a) fewer different generators, and have a shareable version of generators for 
everyone to use accross the base
  b) a testing tool that can be useful for both trivial cases, and complex 
scenarios
myself and many other Cassandra contributors have expressed an opinion that 
bringing Harry in-tree will be highly benefitial.

I strongly believe that bringing Harry in-tree will help to lower the barrier 
for fuzz test and simplify co-development of Cassandra and Harry. Previously, 
it has been rather difficult to debug edge cases because I had to either 
re-compile an in-jvm dtest jar and bring it to Harry, or re-compile a Harry jar 
and bring it to Cassandra, which is both tedious and time consuming. Moreover, 
I believe we have missed at very least one RT regression [2] because Harry was 
not in-tree, as its tests would've caught the issue even with the model that 
existed.

For other recently found issues, I think having Harry in-tree would have 
substantially lowered a turnaround time, and allowed me to share repros with 
developers of corresponding features much quicker.

I do expect a slight learning curve for Harry, but my intention is to build a 
web of simple tests (worked on some of them yesterday after conversation with 
David already), which can follow the in-jvm-dtest pattern of find-similar-test 
/ copy / modify. There's already copious documentation, so I do not believe not 
having docs for Harry was ever an issue, since there have been plenty.

You all are aware of my dedication to testing and quality of Apache Cassandra, 
and I hope you also see the benefits of having a model checker in-tree.

Thank you and happy upcoming 

[USRP-users] Re: CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design contains one or more evaluation cores that will cease to function after a certain period of time. This desig

[German Farinas]

Update on this. Looking at the build log I found this:

Evaluation cores found in this design:
IP core 'ten_gig_eth_pcs_pma' (ten_gig_eth_pcs_pma_v6_0_19) was
generated using a design_linking license.

Resolution: If a new IP Core license was added, in order for the new
license to be picked up, the current netlist needs to be updated by
resetting and re-generating the IP output products before bitstream
generation.

How do I regenerate the IP core?

Best,
German

On Wed, Dec 20, 2023 at 10:48 PM German Farinas 
wrote:

> Hello,
>
> I ran the example in this guide (
> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0) to add a new
> FFT RFNoC block. I modify the default yaml file and run the following
> command:
>
> rfnoc_image_builder -y x300_with_fft.yml -t X300_HG -F ../../../
>
> Everything went well and the bitstream file was successfully generated. I
> uploaded to my USRP X300 with the following command: uhd_image_loader
> --args "type=x300,addr=192.168.10.2" --fpga-path
> ./build/usrp_x300_fpga_HG.bin
>
> after loading the new image this is the output to the *uhd_usrp_probe
> --args type=x300* command:
>
> RFNoC blocks on this device:
> |   |
> |   |   * 0/DDC#0
> |   |   * 0/DDC#1
> |   |   * 0/DUC#0
> |   |   * 0/DUC#1
> |   |   * 0/FFT#0
> |   |   * 0/Radio#0
> |   |   * 0/Radio#1
> |   |   * 0/Replay#0
> | _
> |/
> |   |   Static connections on this device:
> |   |
> |   |   * 0/SEP#0:0==>0/DUC#0:0
> |   |   * 0/DUC#0:0==>0/Radio#0:0
> |   |   * 0/Radio#0:0==>0/DDC#0:0
> |   |   * 0/DDC#0:0==>0/SEP#0:0
> |   |   * 0/Radio#0:1==>0/DDC#0:1
> |   |   * 0/DDC#0:1==>0/SEP#1:0
> |   |   * 0/SEP#2:0==>0/DUC#1:0
> |   |   * 0/DUC#1:0==>0/Radio#1:0
> |   |   * 0/Radio#1:0==>0/DDC#1:0
> |   |   * 0/DDC#1:0==>0/SEP#2:0
> |   |   * 0/Radio#1:1==>0/DDC#1:1
> |   |   * 0/DDC#1:1==>0/SEP#3:0
> |   |   * 0/SEP#4:0==>0/Replay#0:0
> |   |   * 0/Replay#0:0==>0/SEP#4:0
> |   |   * 0/SEP#5:0==>0/Replay#0:1
> |   |   * 0/Replay#0:1==>0/SEP#5:0
> |   |   * 0/SEP#6:0==>0/FFT#0:0
> |   |   * 0/FFT#0:0==>0/SEP#6:0
>
> Everything apparently looks good because the FFT was inserted. However
> during the last phase of the vivado tools flow, after synthesis, place,
> route, etc, during the *BUILDER: Writing bitfile *phase it issues the
> following supposedly critical warning:
>
> *CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This
> design contains one or more evaluation cores that will cease to function
> after a certain period of time. This design should NOT be used in
> production systems.*
>
> I think it may be the FFT IP core but I am not sure. I have Vivado
> v2021.1_AR76780 ML with an Enterprise Edition license. The version is 2021
> because this is the version supported by Ettus for building FPGA images. My
> license goes up to 2023.1 limit, but this should not affect me because I am
> using the 2021 version. I compiled the default images and I don't recall
> receiving this critical warning.
>
> Anyone had the same issue? Any help or explanation to this? Is this
> something I should worry about ?
>
> Best regards,
> German
>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design contains one or more evaluation cores that will cease to function after a certain period of time. This design sh

[German Farinas]

Hello,

I ran the example in this guide (
https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0) to add a new
FFT RFNoC block. I modify the default yaml file and run the following
command:

rfnoc_image_builder -y x300_with_fft.yml -t X300_HG -F ../../../

Everything went well and the bitstream file was successfully generated. I
uploaded to my USRP X300 with the following command: uhd_image_loader
--args "type=x300,addr=192.168.10.2" --fpga-path
./build/usrp_x300_fpga_HG.bin

after loading the new image this is the output to the *uhd_usrp_probe
--args type=x300* command:

RFNoC blocks on this device:
|   |
|   |   * 0/DDC#0
|   |   * 0/DDC#1
|   |   * 0/DUC#0
|   |   * 0/DUC#1
|   |   * 0/FFT#0
|   |   * 0/Radio#0
|   |   * 0/Radio#1
|   |   * 0/Replay#0
| _
|/
|   |   Static connections on this device:
|   |
|   |   * 0/SEP#0:0==>0/DUC#0:0
|   |   * 0/DUC#0:0==>0/Radio#0:0
|   |   * 0/Radio#0:0==>0/DDC#0:0
|   |   * 0/DDC#0:0==>0/SEP#0:0
|   |   * 0/Radio#0:1==>0/DDC#0:1
|   |   * 0/DDC#0:1==>0/SEP#1:0
|   |   * 0/SEP#2:0==>0/DUC#1:0
|   |   * 0/DUC#1:0==>0/Radio#1:0
|   |   * 0/Radio#1:0==>0/DDC#1:0
|   |   * 0/DDC#1:0==>0/SEP#2:0
|   |   * 0/Radio#1:1==>0/DDC#1:1
|   |   * 0/DDC#1:1==>0/SEP#3:0
|   |   * 0/SEP#4:0==>0/Replay#0:0
|   |   * 0/Replay#0:0==>0/SEP#4:0
|   |   * 0/SEP#5:0==>0/Replay#0:1
|   |   * 0/Replay#0:1==>0/SEP#5:0
|   |   * 0/SEP#6:0==>0/FFT#0:0
|   |   * 0/FFT#0:0==>0/SEP#6:0

Everything apparently looks good because the FFT was inserted. However
during the last phase of the vivado tools flow, after synthesis, place,
route, etc, during the *BUILDER: Writing bitfile *phase it issues the
following supposedly critical warning:

*CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This design
contains one or more evaluation cores that will cease to function after a
certain period of time. This design should NOT be used in production
systems.*

I think it may be the FFT IP core but I am not sure. I have Vivado
v2021.1_AR76780 ML with an Enterprise Edition license. The version is 2021
because this is the version supported by Ettus for building FPGA images. My
license goes up to 2023.1 limit, but this should not affect me because I am
using the 2021 version. I compiled the default images and I don't recall
receiving this critical warning.

Anyone had the same issue? Any help or explanation to this? Is this
something I should worry about ?

Best regards,
German
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Re: Future direction for the row cache and OHC implementation

[German Eichberger via dev]

Hi,

we once did some extensive performance testing on the row cache (motivated by 
some hardware accelerator we were hoping to introduce)  but could only find 
improvements in highly contrived scenarios - has been a while since then so 
fresh eyes are good but I think we will still arrive at the conclusion to 
deprecate the row cache.

Thanks,
German

From: Jon Haddad 
Sent: Monday, December 18, 2023 10:31 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: Future direction for the row cache and OHC 
implementation

You don't often get email from j...@jonhaddad.com. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Sure, I’d love to work with you on this.

—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com<http://rustyrazorblade.com/>


On Mon, Dec 18, 2023 at 8:30 AM Ariel Weisberg 
mailto:ar...@weisberg.ws>> wrote:
Hi,

Thanks for the generous offer. Before you do that can you give me a chance to 
add back support for Caffeine for the row cache so you can test the option of 
switching back to an on-heap row cache?

Ariel

On Thu, Dec 14, 2023, at 9:28 PM, Jon Haddad wrote:
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 so this 
is actually kind of perfect for me.  I can take a look in January when I'm back 
from the holidays.

Jon

On Thu, Dec 14, 2023 at 5:44 PM Mick Semb Wever 
mailto:m...@apache.org>> wrote:



I would avoid taking away a feature even if it works in narrow set of 
use-cases. I would instead suggest -

1. Leave it disabled by default.
2. Detect when Row Cache has a low hit rate and warn the operator to turn it 
off. Cassandra should ideally detect this and do it automatically.
3. Move to Caffeine instead of OHC.

I would suggest having this as the middle ground.



Yes, I'm ok with this. (2) can also be a guardrail: soft value when to warn, 
hard value when to disable.

[USRP-users] Building fpga image with online one Ethernet interface

[German Farinas]

Hello All,

I have a USRP x300 and I want to build my custom image. I would like to
drive an array of 4 Tx/Rx antennas in the HF band for ionospheric research,
i.e beam steering monostatic pulse radar.

This is my idea for a custom built:

Since I will use 4 daughterboards 2 LFTX and 2 LFRX mounted on the X300.
Each LFTX or LFRX have 2 port that can be used independently or as a single
I/Q input. I will use it independently. Then, I will have available 4 Rx
ports and 4 Tx ports. The Radio connections would be the following:

For the receiver chain: Radio 0 port 0, Radio 0 port 1, Radio 0 port 2 and
Radio 0 port 3 would be connected to an adder, the output of the adder to a
DDC chain, and the output of the DDC chain to a streamer. In that way all 4
Rx signal would be summed before passing through the DDC chain and I would
save space in FPGA.

For the transmitter chain the only difference is that I would connect the
output of the DUC to a delay line filter and from there extract the 4
outputs to the 4 Tx ports available on the daughterboards. This delay line
should be configurable since from there I would change the steering of the
beam.

Also I would like to use only one 1Gb Ethernet and not both, so I could
save FPGA space. In summary this would be the rfnoc blocks: 2 Radio
interfaces, 1 DDC, 1DUC, 1 custom delay line block, and only 1Gb interface.
I think this may occupy less space than the default image.  One of the many
doubts that I have is about the radio interfaces, in the default image
these radio interfaces have only 2 port, for example Radio 0:0 and Radio
0:1, but I would need also Radio 0:2 and Radio 0:3. The same for Radio 1: 0
to 3. Because I will use all the ports availables in the doughterboards.

I know this is a general and tricky question and I apologize in advance.
But any any help would be very appreciated.

Best,
German
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Including Smart Campaigns in Data Retrieval with Google Ads Scripts

[German]

Hello,

I'm currently working with Google Ads Scripts and facing a challenge in 
retrieving data from Smart Campaigns. Despite my efforts, my script only 
processes regular campaigns and seems to exclude Smart Campaigns. I've 
tried various approaches, including increasing batch sizes and iterating 
over all campaigns, but Smart Campaigns are still not included in the 
output.

Could anyone provide insights or guidance on how to include Smart Campaigns 
in script data retrieval? Are there specific methods or considerations for 
handling Smart Campaigns in Google Ads Scripts?

Thank you for your assistance.

-- 
-- 
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog:
https://googleadsdeveloper.blogspot.com/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

You received this message because you are subscribed to the Google
Groups "AdWords API and Google Ads API Forum" group.
To post to this group, send email to adwords-api@googlegroups.com
To unsubscribe from this group, send email to
adwords-api+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/adwords-api?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Google Ads API and AdWords API Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to adwords-api+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/adwords-api/af8809b0-4caa-4dc5-900e-46c1cbad2cdfn%40googlegroups.com.

Re: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co

[Samolyuk, German D. via Wien]

>This depends on how you start the EIGN calculation. From a scalar
>relativistic GGA+U calculation or just from GGA ??

I started from GGA+U scalar relativistic

>Not a big surprise. During the scf cycle the potential changes.
>Remember, by adding a constant potential, the EIGEN values would change
>by shift*NE, but the potential energy would also shift in opposite
>direction by -shift*NE, so Etot remains constant, but EIGEN not. (NE ..
>number of electrons)

Is it possible to output the shift value? It will allow to shift ebnd by the 
same value in both magnetization direction calculations. I don't expect to have 
the same MAE energy values, but if EBND gives main contribution to the value 
obtained from total energy difference it will be meaningful  to discuss.

Thank you detailed explanation. I really appreciate it

German

Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)

From: Wien  on behalf of Peter Blaha 

Sent: Friday, December 1, 2023 2:27 AM
To: A Mailing list for WIEN2k users 
Subject: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U 
on Co


Initially I executed calculation in the "spirit of force theorem" with
just one iteration and obtained well converged K value calculated from
EIGEN. However reviewer mentioned that force theorem is not obeyed in
case of +U calculation - corrections are not in second order. He is
right, the K value obtained from full scf calculations and total energy
difference is ~40% higher. For just GGA both approaches gives the same
result.
---

This depends on how you start the EIGN calculation. From a scalar
relativistic GGA+U calculation or just from GGA ??

And in addition it is probably again a problem of symmetry. Reliable
values can only be obtained with identical symmetry in the scalarel and
SO calculation. So you have to perform the scalarel. calc with the same
struct file (symmetry operations) and case.in2c (LM combinations) as the
2 SO calculations.

It is NOT only a matter of k-points and cannot be "fixed by x kgen -fbz
---
---
What surprises me is the non-monotonic dependence of K value as a number
of k-points. At the same time K calculated from the total energy
converged. While, the  band structure energy is part of the total energy.
--
Not a big surprise. During the scf cycle the potential changes.
Remember, by adding a constant potential, the EIGEN values would change
by shift*NE, but the potential energy would also shift in opposite
direction by -shift*NE, so Etot remains constant, but EIGEN not. (NE ..
number of electrons)

--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: 
https://urldefense.us/v2/url?u=http-3A__www.wien2k.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=2rJoswOBQ92PKOEckFLkl8FPEmeAYw5-vJ6W5FNVUsIRT9dNeM3rsFcJOTPpNFJb=8Bc_0Dag-FLMvY2FdwzRLEjWbmXdtmAew2_77xLIJkg=
WWW:   
https://urldefense.us/v2/url?u=http-3A__www.imc.tuwien.ac.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=2rJoswOBQ92PKOEckFLkl8FPEmeAYw5-vJ6W5FNVUsIRT9dNeM3rsFcJOTPpNFJb=DzH1tAa_e6jpwNi0n5EBke6n2M4jAHbZpKYBS3ISpC8=
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=2rJoswOBQ92PKOEckFLkl8FPEmeAYw5-vJ6W5FNVUsIRT9dNeM3rsFcJOTPpNFJb=3kFudcBlmqk8rCLFIS8Q6qbM3pxWK9eXVxgLnGDlinE=
SEARCH the MAILING-LIST at:  
https://urldefense.us/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=2rJoswOBQ92PKOEckFLkl8FPEmeAYw5-vJ6W5FNVUsIRT9dNeM3rsFcJOTPpNFJb=sqNi0wE0N-5TvU2CVqKzeYBfBb4jjrcIwejWUItyZYw=
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: Cassandra Summit: Engage those networks!

[German Eichberger via user]

+1 we will be two people from the Microsoft Cassandra team this time around 

From: Paulo Motta 
Sent: Wednesday, November 29, 2023 7:11 PM
To: user@cassandra.apache.org 
Subject: [EXTERNAL] Re: Cassandra Summit: Engage those networks!

This Cassandra Summit is going to be epic!
Looking forward to meet the Cassandra community in two weeks! 落

On Wed, 29 Nov 2023 at 18:26 Patrick McFadin 
mailto:pmcfa...@gmail.com>> wrote:
Hi everyone,

We are a couple of weeks away from Cassandra Summit. People get busy and forget 
to register or miss that there is even a summit happening. Let's make sure 
everyone who wants to go gets a chance!

 - If you are going, get on the social media of your choice and let everyone 
know you'll be there. Use the hashtag #cassandrasmunnit
 - If you aren't going, you can still remind other folks that it's happening 
and the talks you think they should check out.

Either way, here is the basic info to include in your post:


Schedule: https://events.linuxfoundation.org/cassandra-summit/program/schedule/

Register: 
https://events.linuxfoundation.org/cassandra-summit/register/#register-now

Discount code: 23CS20

One more thing! If you are going and reading this, reply to this email with a 
"Going!" or "See you there!" I would love to see who will be there in two weeks.

Patrick

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[German Eichberger via dev]

I don't think outside people will know the distinction between alpha and beta - 
for them anything which isn't GA doesn't get deployed  (and even then they 
might wait another year or two).

People following this mailing list would lilkey know that 5.0-beta-1 is pretty 
close to 5.0-alpha-3 -- so I am supporting releasing to hit the date, At this 
point it's semantics...

Thanks,
German

From: Maxim Muzafarov 
Sent: Thursday, November 30, 2023 3:12 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-beta1

I'm gonna take a moment to outline the question. Here we have a point
in time where a time-driven release process clashes with the
alpha/beta release naming convention: we want to have a beta ready
_before_ the Summit.

Here's the Cassandra release lifecycle document [1] that I found
(still under discussion I think) and according to the 'beta'
definition we should have a green CI and no regressions for a beta
release.  This means that there may be known bugs in the new features
we are trying to ship. Unless I'm not missing something, 5.0 currently
meets the 'beta' criteria and the definition itself sounds clear to
me.

So, the question is - should we find a better place for the [1] page
and move it somewhere under the 'officially accepted'? :-)

[1] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FCASSANDRA%2FRelease%2BLifecycle=05%7C01%7CGerman.Eichberger%40microsoft.com%7C1ec418c7eb5040f7acaf08dbf1955153%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638369395848575700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hE9tInVzW9GAhR7IbuMASiOpTaHuaMb9455HVBRaMx4%3D=0<https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle>

On Thu, 30 Nov 2023 at 07:39, Jacek Lewandowski
 wrote:
>>
>> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it 
>> will signal to the community that we’re prioritizing stability and it could 
>> be a good opportunity to get people to test the beta or RC before we stamp 
>> it as production ready.
>
>
> I agree with Paulo's comment
>
> czw., 30 lis 2023 o 04:44 Paulo Motta  napisał(a):
>>
>> > if any contributor has an opinion which is not technically refuted it will 
>> > usually be backed by a PMC via a binding -1
>>
>> clarifying a bit my personal view: if any contributor has an opinion against 
>> a proposal (in this case this release proposal) that is not refuted it will 
>> usually be backed by a PMC via binding -1
>>
>> Opinions supporting the proposal are also valuable, provided there are no 
>> valid claims against a proposal.
>>
>> On Wed, 29 Nov 2023 at 22:27 Paulo Motta  wrote:
>>>
>>> To me, the goal of a beta is to find unknown bugs. If no new bugs are found 
>>> during a beta release, then it can be automatically promoted to RC via 
>>> re-tagging. Likewise, if no new bugs are found during a RC after X time, 
>>> then it can be promoted to final.
>>>
>>> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it 
>>> will signal to the community that we’re prioritizing stability and it could 
>>> be a good opportunity to get people to test the beta or RC before we stamp 
>>> it as production ready.
>>>
>>> WDYT?
>>>
>>> >  Aaron (and anybody who takes the time to follow this list, really), your 
>>> > opinion matters, that's why we discuss it here.
>>>
>>> +1, PMC are just officers who endorse community decisions, so if any 
>>> contributor has an opinion which is not technically refuted it will usually 
>>> be backed by a PMC via a binding -1 (as seen on this thread)
>>>
>>> On Wed, 29 Nov 2023 at 20:04 Nate McCall  wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko  
>>>> wrote:
>>>>>
>>>>> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now, 
>>>>> but I’m not sure there is significant value to be had from it. Merge the 
>>>>> fixes for outstanding issues listed above, then cut beta1.
>>>>
>>>> 
>>>>
>>>> Agree with Aleksey. -1 on a beta we know has issues with a top-line new 
>>>> feature.
>>>>
>>>>

Re: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co

[Samolyuk, German D. via Wien]

I did  self consistent calculations for each magnetization orientations


  1.  in directory with name 100 run init_so_lapw
  2.  choose [1 0 0] magnetization orientation
  3.  copy directory to the new one with name 001
  4.  in directory 001 rename names 100 to 001
  5.  in directory 001 change magnetization orientation in 001.inso to 001
  6.  runsp -so -orb -dm -p -ec 0.01 -NI -i 200 on both directories


after finishing
for total energy
>grep :ENE case.scf
for band structure part
>grep EIGN case.scf

to increase k mesh

  1.  go to directory 100
  2.  x kgen -so
  3.  cp 100.klist ../001/001.klist; cp 100.kgen ../001/001.kgen
  4.
runsp -so -orb -dm -p -ec 0.01 -NI -i 200 on both directories

after finishing
for total energy
>grep :ENE case.scf
for band structure part
>grep EIGN case.scf


Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)

From: Wien  on behalf of Peter Blaha 

Sent: Wednesday, November 29, 2023 4:37 PM
To: wien@zeus.theochem.tuwien.ac.at 
Subject: Re: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with 
GGA+U on Co

For Eigen you do just ONE iteration ?

But how did you start the calculations ?

I need your commands, exactly as you typed them (not only the last one,
but all the essential history ...)

Am 29.11.2023 um 21:07 schrieb Samolyuk, German D. via Wien:
> I take last set from
>  >grep EIGEN case.scf
> for two orientations
>
> The values in case.scf2up and case.scf2dn are the same
>
> Dr. German D Samolyuk
> Materials Theory Group
> Materials Science & Technology Division
> Oak Ridge National Laboratory
> Post Office Box 2008
> Oak Ridge, TN 37831-6138
> (865) 241-5394
> (865) 241-3650 (FAX)
> 
> *From:* Wien  on behalf of
> Peter Blaha 
> *Sent:* Wednesday, November 29, 2023 2:57 PM
> *To:* wien@zeus.theochem.tuwien.ac.at 
> *Subject:* [EXTERNAL] Re: [Wien] YCo5 magnetic anisotropy calculations
> with GGA+U on Co
> Please list all the steps you do for the EBND calculation for the GGA+U
> case.
> I'd expect you do something wrong in this case.
>
>
> Am 28.11.2023 um 20:22 schrieb Samolyuk, German D. via Wien:
>> Dear colleagues,
>>
>> I'm calculating magnetic anisotropy in YCo5 within GGA+U approach with
>> U-J=0.08 Ry Co d-states, wien2k_19.
>>
>> To obtain the MAE, K, value the fully self-consistent calculations were
>> executed for in plane and along z-axis magnetic moment orientation. the
>> self-consistency is important for case of GGA+U.
>> Three sets of calculations were executed 1) keep 8 symmetry operation
>> obtained for [100] moment orientation, 2) keep 8 symmetry operations
>> obtained for [110] operations, 3) one E symmetry operation - full BZ
>> integration.
>> The MAE energy is calculated 1) as total energy difference 2) as a
>> difference of band structure energy, EBND.
>>
>> Following results were obtained:
>>  >1)
>> 100 - 8 SYM OP:
>> nk=16x16x17-5000: K = 6.53575196338352 meV/fu
>> nk=18x18x20-7000: K = 6.49467997718602 meV/fu
>> nk=16x16x17-5000: K = 15.4869591999841 meV/fu - EBND
>> nk=18x18x20-7000: K = -5.3348728267 meV/fu - EBND
>>  >2)
>> [110] - 8 SYM OP:
>> 16x16x17-5000: K = 6.56594401516486 meV/fu
>> 18x18x20-7000: K = 6.47836000134703 meV/fu
>> 16x16x17-5000: K = 23.350166399905 meV/fu - EBND
>> 18x18x20-7000: K = 24.0896663999706 meV/fu - EBND
>>  >3)
>> FBZ - 1 SYM OP:
>> 16x16x17-5000: K = 6.48733603011351 meV/fu
>> 18x18x20-7000: K = 6.45932000479661 meV/fu
>> 16x16x17-5000: K = -23.450821642 meV/fu - EBND
>> 18x18x20-7000: K = -14.726882399907 meV/fu - EBND
>>
>> The total energy results for MAE, K, are well converged and insensitive
>> to in-plane magnetization orientation.
>> While, K value calculated from band structure energy, EBND, behaved strange.
>> Expectedly, both ways of K calculation gives close result for regular
>> GGA (the force theorem).
>>
>> Do you know what is source of such irregular EBND difference behavior
>> for GGA+U calculaions?
>> Thank you,
>>
>> German
>>
>>
>> Dr. German D Samolyuk
>> Materials Theory Group
>> Materials Science & Technology Division
>> Oak Ridge National Laboratory
>> Post Office Box 2008
>> Oak Ridge, TN 37831-6138
>> (865) 241-5394
>> (865) 241-3650 (FAX)
>>
>> ___
>> Wien mailing list
>> 

Re: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co

[Samolyuk, German D. via Wien]

I'm sorry for possible confusion, by the same I meant the same as in case.scf

Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)

From: Wien  on behalf of Peter Blaha 

Sent: Wednesday, November 29, 2023 2:57 PM
To: wien@zeus.theochem.tuwien.ac.at 
Subject: [EXTERNAL] Re: [Wien] YCo5 magnetic anisotropy calculations with GGA+U 
on Co

Please list all the steps you do for the EBND calculation for the GGA+U
case.
I'd expect you do something wrong in this case.


Am 28.11.2023 um 20:22 schrieb Samolyuk, German D. via Wien:
> Dear colleagues,
>
> I'm calculating magnetic anisotropy in YCo5 within GGA+U approach with
> U-J=0.08 Ry Co d-states, wien2k_19.
>
> To obtain the MAE, K, value the fully self-consistent calculations were
> executed for in plane and along z-axis magnetic moment orientation. the
> self-consistency is important for case of GGA+U.
> Three sets of calculations were executed 1) keep 8 symmetry operation
> obtained for [100] moment orientation, 2) keep 8 symmetry operations
> obtained for [110] operations, 3) one E symmetry operation - full BZ
> integration.
> The MAE energy is calculated 1) as total energy difference 2) as a
> difference of band structure energy, EBND.
>
> Following results were obtained:
>  >1)
> 100 - 8 SYM OP:
> nk=16x16x17-5000: K = 6.53575196338352 meV/fu
> nk=18x18x20-7000: K = 6.49467997718602 meV/fu
> nk=16x16x17-5000: K = 15.4869591999841 meV/fu - EBND
> nk=18x18x20-7000: K = -5.3348728267 meV/fu - EBND
>  >2)
> [110] - 8 SYM OP:
> 16x16x17-5000: K = 6.56594401516486 meV/fu
> 18x18x20-7000: K = 6.47836000134703 meV/fu
> 16x16x17-5000: K = 23.350166399905 meV/fu - EBND
> 18x18x20-7000: K = 24.0896663999706 meV/fu - EBND
>  >3)
> FBZ - 1 SYM OP:
> 16x16x17-5000: K = 6.48733603011351 meV/fu
> 18x18x20-7000: K = 6.45932000479661 meV/fu
> 16x16x17-5000: K = -23.450821642 meV/fu - EBND
> 18x18x20-7000: K = -14.726882399907 meV/fu - EBND
>
> The total energy results for MAE, K, are well converged and insensitive
> to in-plane magnetization orientation.
> While, K value calculated from band structure energy, EBND, behaved strange.
> Expectedly, both ways of K calculation gives close result for regular
> GGA (the force theorem).
>
> Do you know what is source of such irregular EBND difference behavior
> for GGA+U calculaions?
> Thank you,
>
> German
>
>
> Dr. German D Samolyuk
> Materials Theory Group
> Materials Science & Technology Division
> Oak Ridge National Laboratory
> Post Office Box 2008
> Oak Ridge, TN 37831-6138
> (865) 241-5394
> (865) 241-3650 (FAX)
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=nf3gP4WvSgZ0WXQixWNclwYcFOw9C2S4-fB9Km9aE90=
> SEARCH the MAILING-LIST at:  
> https://urldefense.us/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=FG4ImVhTGdAMvrN_wwV3CigER_LipQfvTaP957uSDjE=

--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: 
https://urldefense.us/v2/url?u=http-3A__www.wien2k.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=IitTpMm41OFhN-Au4l57q3yUam7I8dV_VlmLzKwEpMg=
WWW:   
https://urldefense.us/v2/url?u=http-3A__www.imc.tuwien.ac.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=glau7RiwZ1MSLg1c_eje7Osh4VPsrX0zKeoUeUy42Uc=
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=nf3gP4WvSgZ0WXQixWNclwYcFOw9C2S4-fB9Km9aE90=
SEARCH the MAILING-LIST at:  
https://urldefense.us/v2/url?u=http-3A__www.mail-2Darchive.co

Re: [Wien] [EXTERNAL] Re: YCo5 magnetic anisotropy calculations with GGA+U on Co

[Samolyuk, German D. via Wien]

I take last set from
>grep EIGEN case.scf
for two orientations

The values in case.scf2up and case.scf2dn are the same

Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)

From: Wien  on behalf of Peter Blaha 

Sent: Wednesday, November 29, 2023 2:57 PM
To: wien@zeus.theochem.tuwien.ac.at 
Subject: [EXTERNAL] Re: [Wien] YCo5 magnetic anisotropy calculations with GGA+U 
on Co

Please list all the steps you do for the EBND calculation for the GGA+U
case.
I'd expect you do something wrong in this case.


Am 28.11.2023 um 20:22 schrieb Samolyuk, German D. via Wien:
> Dear colleagues,
>
> I'm calculating magnetic anisotropy in YCo5 within GGA+U approach with
> U-J=0.08 Ry Co d-states, wien2k_19.
>
> To obtain the MAE, K, value the fully self-consistent calculations were
> executed for in plane and along z-axis magnetic moment orientation. the
> self-consistency is important for case of GGA+U.
> Three sets of calculations were executed 1) keep 8 symmetry operation
> obtained for [100] moment orientation, 2) keep 8 symmetry operations
> obtained for [110] operations, 3) one E symmetry operation - full BZ
> integration.
> The MAE energy is calculated 1) as total energy difference 2) as a
> difference of band structure energy, EBND.
>
> Following results were obtained:
>  >1)
> 100 - 8 SYM OP:
> nk=16x16x17-5000: K = 6.53575196338352 meV/fu
> nk=18x18x20-7000: K = 6.49467997718602 meV/fu
> nk=16x16x17-5000: K = 15.4869591999841 meV/fu - EBND
> nk=18x18x20-7000: K = -5.3348728267 meV/fu - EBND
>  >2)
> [110] - 8 SYM OP:
> 16x16x17-5000: K = 6.56594401516486 meV/fu
> 18x18x20-7000: K = 6.47836000134703 meV/fu
> 16x16x17-5000: K = 23.350166399905 meV/fu - EBND
> 18x18x20-7000: K = 24.0896663999706 meV/fu - EBND
>  >3)
> FBZ - 1 SYM OP:
> 16x16x17-5000: K = 6.48733603011351 meV/fu
> 18x18x20-7000: K = 6.45932000479661 meV/fu
> 16x16x17-5000: K = -23.450821642 meV/fu - EBND
> 18x18x20-7000: K = -14.726882399907 meV/fu - EBND
>
> The total energy results for MAE, K, are well converged and insensitive
> to in-plane magnetization orientation.
> While, K value calculated from band structure energy, EBND, behaved strange.
> Expectedly, both ways of K calculation gives close result for regular
> GGA (the force theorem).
>
> Do you know what is source of such irregular EBND difference behavior
> for GGA+U calculaions?
> Thank you,
>
> German
>
>
> Dr. German D Samolyuk
> Materials Theory Group
> Materials Science & Technology Division
> Oak Ridge National Laboratory
> Post Office Box 2008
> Oak Ridge, TN 37831-6138
> (865) 241-5394
> (865) 241-3650 (FAX)
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=nf3gP4WvSgZ0WXQixWNclwYcFOw9C2S4-fB9Km9aE90=
> SEARCH the MAILING-LIST at:  
> https://urldefense.us/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=FG4ImVhTGdAMvrN_wwV3CigER_LipQfvTaP957uSDjE=

--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: 
https://urldefense.us/v2/url?u=http-3A__www.wien2k.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=IitTpMm41OFhN-Au4l57q3yUam7I8dV_VlmLzKwEpMg=
WWW:   
https://urldefense.us/v2/url?u=http-3A__www.imc.tuwien.ac.at=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=glau7RiwZ1MSLg1c_eje7Osh4VPsrX0zKeoUeUy42Uc=
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=ehUR2Buww5fZnmxtmucvG4rG0eY-ytyOksYJKFcnpSh81YvCsPa_YPLcVgnGV6Xs=nf3gP4WvSgZ0WXQixWNclwYcFOw9C2S4-fB9Km9aE90=
SEARCH the MAILING-LIST at:  
https://urldefense.us

[Wien] YCo5 magnetic anisotropy calculations with GGA+U on Co

[Samolyuk, German D. via Wien]

Dear colleagues,

I'm calculating magnetic anisotropy in YCo5 within GGA+U approach with U-J=0.08 
Ry Co d-states, wien2k_19.

To obtain the MAE, K, value the fully self-consistent calculations were 
executed for in plane and along z-axis magnetic moment orientation. the 
self-consistency is important for case of GGA+U.
Three sets of calculations were executed 1) keep 8 symmetry operation  obtained 
for [100] moment orientation, 2) keep 8 symmetry operations obtained for [110] 
operations, 3) one E symmetry operation - full BZ integration.
The MAE energy is calculated 1) as total energy difference 2) as a difference 
of band structure energy, EBND.

Following results were obtained:
>1)
100 - 8 SYM OP:
nk=16x16x17-5000: K = 6.53575196338352 meV/fu
nk=18x18x20-7000: K = 6.49467997718602 meV/fu
nk=16x16x17-5000: K = 15.4869591999841 meV/fu - EBND
nk=18x18x20-7000: K = -5.3348728267 meV/fu - EBND
>2)
[110] - 8 SYM OP:
16x16x17-5000: K = 6.56594401516486 meV/fu
18x18x20-7000: K = 6.47836000134703 meV/fu
16x16x17-5000: K = 23.350166399905 meV/fu - EBND
18x18x20-7000: K = 24.0896663999706 meV/fu - EBND
>3)
FBZ - 1 SYM OP:
16x16x17-5000: K = 6.48733603011351 meV/fu
18x18x20-7000: K = 6.45932000479661 meV/fu
16x16x17-5000: K = -23.450821642 meV/fu - EBND
18x18x20-7000: K = -14.726882399907 meV/fu - EBND

The total energy results for MAE, K, are well converged and insensitive to 
in-plane magnetization orientation.
While, K value calculated from band structure energy, EBND, behaved strange.
Expectedly, both ways of K calculation gives close result for regular GGA (the 
force theorem).

Do you know what is source of such irregular EBND difference behavior for GGA+U 
calculaions?

Thank you,

German


Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [PRQ#51495] Orphan Request for python-typed-argument-parser

[German Lashevich]

Hi Heiki,

Thank you for updating the package!
Accept my apologies for the inappropriately toned request.
By "not responding" I meant the absence of activity or comments from the
maintainer on the package page in AUR.
Perhaps, this wasn't phrased correctly.

Best regards,
German Lashevich

On Mon, 20 Nov 2023 at 19:20, Heiki Lõhmus  wrote:

> On Sun, Nov 19, 2023 at 01:14:26AM +, not...@aur.archlinux.org wrote:
> > [N]ow it is outdated[.]
>
> No longer true.
>
> > [T]he maintainer is not responding.
>
> I have not received a single e-mail from you. The e-mail address is in
> the PKGBUILD for a reason.
>
>
> Cheers,
> --
> Heiki Lõhmus
>

[dolphin] [Bug 450244] Text is cut off when selected

[German P]

https://bugs.kde.org/show_bug.cgi?id=450244

German P  changed:

   What|Removed |Added

 CC||german...@hotmail.com

--- Comment #6 from German P  ---
I'm also experiencing the issue.

SOFTWARE/OS VERSIONS
Linux: 6.6.2-1-MANJARO
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API

[German Eichberger via dev]

Hi,

>From a cloud provider perspective we expose the storage port to customers for 
>Hybrid scenarios (e.g. fusing on-prem Cassandra with in-cloud Cassandra) so 
>would prefer an extra port or a socket.
Thanks,
German


From: Dinesh Joshi 
Sent: Friday, November 17, 2023 4:06 PM
To: dev 
Subject: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API

Hi Maxim,

Thanks for putting this CEP together! This is a great start. I have gone over 
the CEP and there is one thing that stuck out to me.

Among the 'basic requirements', I see you have this -

> A dedicated admin port with the native protocol behind it,
> allowing only admin commands, to address the concerns when
> the native protocol is disabled in certain circumstances
> e.g. the disablebinary command is executed;

I understand what you're achieve here. However, there are a few reasons we 
should probably offer some choice to our users w.r.t. using a dedicated port 
for management functions.

Today Cassandra exposes several ports - 9042, 9142, 7000 and 7001. The sidecar 
runs on port 9043. Thats a lot of ports. I would prefer to allow users to 
access management functionality over one of the existing ports.

I realize that this would mean a subtle change in behavior for disablebinary 
when we offer it over port 9042 and not when the operator decides to use a 
dedicated port.

More importantly, I think having this functionality exposed over the storage 
ports may be even better. The storage ports are typically firewalled off from 
the end users. Operators and tooling, however, usually have access to these 
ports. This especially makes sense from a security standpoint where we'd like 
to limit users from accessing management functionality.

What do others think about this approach?

thanks,

Dinesh

> On Nov 13, 2023, at 10:08 AM, Maxim Muzafarov  wrote:
>
> Hello everyone,
>
> While we are still waiting for the review to make the settings virtual
> table updatable (CASSANDRA-15254), which will improve the
> configuration management experience for users, I'd like to take
> another step forward and improve the C* management approach we have as
> a whole. This approach aims to make all Cassandra management commands
> accessible via CQL, but not only that.
>
> The problem of making commands accessible via CQL presents a complex
> challenge, especially if we aim to minimize code duplication across
> the implementation of management operations for different APIs and
> reduce the overall maintenance burden. The proposal's scope goes
> beyond simply introducing a new CQL syntax. It encompasses several key
> objectives for C* management operations, beyond their availability
> through CQL:
> - Ensure consistency across all public APIs we support, including JMX
> MBeans and the newly introduced CQL. Users should see consistent
> command specifications and arguments, irrespective of whether they're
> using an API or a CLI;
> - Reduce source code maintenance costs. With this new approach, when a
> new command is implemented, it should automatically become available
> across JMX MBeans, nodetool, CQL, and Cassandra Sidecar, eliminating
> the need for additional coding;
> - Maintain backward compatibility, ensuring that existing setups and
> workflows continue to work the same way as they do today;
>
> I would suggest discussing the overall design concept first, and then
> diving into the CQL command syntax and other details once we've found
> common ground on the community's vision. However, regardless of these
> details, I would appreciate any feedback on the design.
>
> I look forward to your comments!
>
> Please, see the design document: CEP-38: CQL Management API
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FCASSANDRA%2FCEP-38%253A%2BCQL%2BManagement%2BAPI=05%7C01%7CGerman.Eichberger%40microsoft.com%7C510fbe97b579406b389f08dbe7ca5430%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638358628430485779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=aJcomfk5ufDIUqTFmUWzuvR18cFL8qAUS%2F3XwffqVqs%3D=0<https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API>

NOTICE: virtio-fs list migration

[German Maglione]

The mailing list virtio...@redhat.com has been migrated to
lists.linux.dev, this change was required due to listman.redhat.com
will be moved to an alternative hosting solution.

The new address for posting will be:

virtio-fs@lists.linux.dev

This change does _not_ require any action on your part, all list
members have been subscribed to the new list, maintaining their
subscription preferences (regular or digest).

Email archives are also migrated from
https://listman.redhat.com/archives/virtio-fs/, to
https://lore.kernel.org/virtio-fs/ this change will result in broken
links to the old email archive.

Sorry for any inconvenience this may cause you.


-- 
German

Re: [DISCUSSION] CEP-38: CQL Management API

[German Eichberger via dev]

Hi Maxim,

We have adopted/forked the agent part of the 
https://github.com/k8ssandra/management-api-for-apache-cassandra project which 
aims to do similar things. I especially like how they have a local database 
socket where a sidecar can easily access cassandra and execute cql commands 
without the need of a service account like your example suggests.

The syntax they adopted (see for instance 
https://github.com/k8ssandra/management-api-for-apache-cassandra/blob/7cb367eac46a12947bb87486456d3f905f37628b/management-api-server/src/main/java/com/datastax/mgmtapi/resources/NodeOpsResources.java#L115)
 looks like `CALL NodeOps.decommission(?, ?)", force, false)` which is similar 
to your execute - just throwing this out as another example.

I definitely like settling on the cql interface since that avoids having to 
load different jmx bindings for different Cassandra versions making things 
cleaner and more easily accessible. There is some security concern to mix data 
and control plane so I would liek to see some way to restrict access like the 
mgmt api does where the admin commands are only available on the socket. Maybe, 
have a special admin port or socket?

I  prefer making the agent part of the managment api become part of Cassandra 
either through your CEP or other means but I can also see this as an adjacent 
sub project  - let's discuss 

German


From: Maxim Muzafarov 
Sent: Monday, November 13, 2023 10:08 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] [DISCUSSION] CEP-38: CQL Management API

Hello everyone,

While we are still waiting for the review to make the settings virtual
table updatable (CASSANDRA-15254), which will improve the
configuration management experience for users, I'd like to take
another step forward and improve the C* management approach we have as
a whole. This approach aims to make all Cassandra management commands
accessible via CQL, but not only that.

The problem of making commands accessible via CQL presents a complex
challenge, especially if we aim to minimize code duplication across
the implementation of management operations for different APIs and
reduce the overall maintenance burden. The proposal's scope goes
beyond simply introducing a new CQL syntax. It encompasses several key
objectives for C* management operations, beyond their availability
through CQL:
- Ensure consistency across all public APIs we support, including JMX
MBeans and the newly introduced CQL. Users should see consistent
command specifications and arguments, irrespective of whether they're
using an API or a CLI;
- Reduce source code maintenance costs. With this new approach, when a
new command is implemented, it should automatically become available
across JMX MBeans, nodetool, CQL, and Cassandra Sidecar, eliminating
the need for additional coding;
- Maintain backward compatibility, ensuring that existing setups and
workflows continue to work the same way as they do today;

I would suggest discussing the overall design concept first, and then
diving into the CQL command syntax and other details once we've found
common ground on the community's vision. However, regardless of these
details, I would appreciate any feedback on the design.

I look forward to your comments!

Please, see the design document: CEP-38: CQL Management API
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FCASSANDRA%2FCEP-38%253A%2BCQL%2BManagement%2BAPI=05%7C01%7CGerman.Eichberger%40microsoft.com%7C62051e1eb8964889962d08dbe473d482%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638354958369996874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=XT4LB1CopZy8qCUM6MnUfBhGFwKHmsUO%2B2AUpgv83zI%3D=0<https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API>

Re: [PATCH] MAINTAINERS: update virtio-fs mailing list address

[German Maglione]

On Sat, Nov 11, 2023 at 1:49 AM Stefan Hajnoczi  wrote:
>
> The old virtio-fs mailing list address is no longer in use. Switch to
> the new mailing list address.
>
> Cc: Philippe Mathieu-Daudé 
> Cc: Vivek Goyal 
> Cc: German Maglione 
> Cc: Hanna Czenczek 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e73a3ff544..c52df9f76c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2241,7 +2241,7 @@ M: Stefan Hajnoczi 
>  S: Supported
>  F: hw/virtio/vhost-user-fs*
>  F: include/hw/virtio/vhost-user-fs.h
> -L: virtio...@redhat.com
> +L: virtio...@lists.linux.dev
>
>  virtio-input
>  M: Gerd Hoffmann 
> --
> 2.41.0
>

Reviewed-by: German Maglione 

--
German

[Comp-neuro] postdoc in paris

[German Sumbre]

  
  
 Postdoc
position at the Ecole normale superieure, Paris, France


The Mexican tetra, Astyanax
mexicanus is a leading model for studying
  genetic mechanisms underlying trait evolution. A. mexicanus consists of a surface (river) and
  several cave populations that independently evolved in largely
  isolated caves, allowing for comparative approaches to
  identify genetic and neural variants associated with
  behavioral evolution. Cave populations of A. mexicanus exhibit prominent changes in
  sensory systems including loss of vision and
  expansion of smell, taste, mechanosensation and lateral line.
  Despite the
robust changes in behavior and morphology, the shifts in
processing sensory information within the brain have
  been unexplored.  
We are looking
  for a postdoc to study the evolution of brain processes and
  computations. For this purpose, we are using transgenic fish
  expressing GCaMP in combination with light-sheet microscopy to
  monitor the activity of the whole brain, with single-neuron
  resolution in an intact, behaving larvae.
We are studying
  the differences in sensory processing, motor control and
  behavioral states between the surface and cavefish, to shed
  light on principles underlying the evolution of brain
  computations.


The lab is located at the Ecole normale
supérieure, paris, France. www.ibens.ens.fr


*For the
  postdoc position, it is necessary to have good programming
  skills, and some background in computational neuroscience.


For more information you can contact Germán
Sumbre sum...@ens.fr


www.zebrain.biologie.ens.fr



  References
Uribe-Arias, A.,et
  al. 2023. Radial astrocyte synchronization modulates the visual
  system during behavioral-state transitions. Neuron
  S0896-6273(23)00709–2. https://doi.org/10.1016/j.neuron.2023.09.022


Lloyd, E., et al.
  2022. Blind cavefish retain functional connectivity in the tectum
  despite loss of retinal input. Current Biology 32,
  2021.09.28.461408. https://doi.org/10.1016/j.cub.2022.07.015


Ponce-Alvarez, A.,
  et al. 2018. Whole-Brain Neuronal Activity Displays Crackling
  Noise Dynamics. Neuron 100, 1446-1459.e6. https://doi.org/10.1016/j.neuron.2018.10.045


Pietri, T., et al.
  2017. The Emergence of the Spatial Structure of Tectal Spontaneous
  Activity Is Independent of Visual Inputs. 
Cell Reports
  19, 939–948. https://doi.org/10.1016/j.celrep.2017.04.015


Romano, S.A., et
  al. 2015. Spontaneous neuronal network dynamics reveal circuit’s
  functional adaptations for behavior. Neuron 85,
  1070–85. https://doi.org/10.1016/j.neuron.2015.01.027



  

[USRP-users] Re: Fwd: The firmware build is not compatible with the host code build

[German Farinas]

An update about this issue.

I built from source 3.15 an still gave me the same error. I even created a
virtual machines with Ubuntu 18.04 and 16.04 and install the standard UHD
package, which are older that 3.15 and still same error message. I am
confused. I think there is another kind of problem. With Ubuntu 18.04 (UHD
3.9 I think) when I tried to upload images I just received a shorter error
message:


Error: RuntimeError: Received invalid reply 32 from device.
___



On Thu, Nov 9, 2023, 8:21 PM Marcus D. Leech 
wrote:

> Those Rev numbers are hardware revs, but it may well also indicate that
> its on-board FPGA image is quite old--old enough that
>   modern image-loader tooling cannot cope, which is why a "hill-climbing"
> approach may be necessary.
>
> I'll note that Ubuntu packaged UHD 3.15 for 20.04 (Focal):
>
> https://packages.ubuntu.com/search?suite=focal=uhd
>
> So, if you can extricate yourself (temporarily) from the UHD 4.5 that you
> likely installed through a PPA, the default
>   UHD package for Ubuntu 20.04 is what you want.
>
>
>
>
>  Forwarded Message 
> Subject: Re: [USRP-users] The firmware build is not compatible with the
> host code build
> Date: Thu, 9 Nov 2023 20:11:41 -0500
> From: German Farinas  
> To: Marcus D. Leech  
> speed
> I have two N210s. One of the USRPs N210 is working fine with UHD 4.5, I
> suppose that one is rev4 although it doesn't say it explicitly at the back
> of the case. However, the other USRP N210 says explicitly rev2 at the back.
> This one is giving me the error.
>
>
> About the motivation for having UHD 4.5 none in specific. I am just new to
> UHD and I installed it via command line in Ubuntu 20. It was just easier.
> But in the future I may work with X300.
>
>
> On Thu, Nov 9, 2023, 7:59 PM Marcus D. Leech 
> wrote:
>
>> On 09/11/2023 19:24, German Farinas wrote:
>>
>> I am using UHD 4.5, I may try 3.15 as you suggested. But I don't know how
>> to install both together. My system is Ubuntu 20.04 LTS.
>>
>> There haven't been any (documented) changes for N210 since UHD 3.13.
>>
>> You may need to build 3.15 from source.I haven't ever really managed
>> two UHD on the same system at the same time.
>>   Some folks like to use a different install prefix when building, and
>> then set LD_LIBRARY_PATH and friends at runtime.
>>   Some folks use docker containers.
>>
>> What is the motivation for using UHD 4.5?  Unless you have hardware on
>> the same system that is much newer, of course.
>>
>>
>>
>>
>> On Thu, Nov 9, 2023, 7:08 PM Marcus D Leech 
>> wrote:
>>
>>> You may need to stage this from a much earlier rev of UHD. I don’t think
>>> there have been any updates to N210 firmware in a long time. So if you can
>>> tolerate UHD 3.15 that might be better for you.
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 9, 2023, at 7:05 PM, German Farinas 
>>> wrote:
>>>
>>> 
>>> I am trying to upload the image to an usrp N210 rev2.0 but I got the
>>> following error message. Have anyone had the same error before? I need some
>>> help with this issue. See the output of the uhd_image_loader below.
>>>
>>> Best,
>>> German
>>>
>>> uhd_image_loader --args="type=usrp2,addr=192.168.10.2"
>>>
>>> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
>>> UHD_4.5.0.0-0ubuntu1~focal1
>>> [ERROR] [UHD] Exception caught in safe-call.
>>>   in ~usrp2_iface_impl
>>>   at /build/uhd-UJYBdq/uhd-4.5.0.0/host/lib/usrp/usrp2/usrp2_iface.cpp:82
>>> this->lock_device(false); -> RuntimeError:
>>> Please update the firmware and FPGA images for your device.
>>> See the application notes for USRP2/N-Series for instructions.
>>> Expected protocol compatibility number [10 to 12], but got 9:
>>> The firmware build is not compatible with the host code build.
>>> Please run:
>>>
>>>  "/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
>>>  "/lib/bin/uhd_image_loader" \
>>> --args="type=usrp2,addr=192.168.10.2"
>>>
>>> Error: RuntimeError: Received invalid reply 32 from device.
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>>
>> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: The firmware build is not compatible with the host code build

[German Farinas]

I am using UHD 4.5, I may try 3.15 as you suggested. But I don't know how
to install both together. My system is Ubuntu 20.04 LTS.




On Thu, Nov 9, 2023, 7:08 PM Marcus D Leech  wrote:

> You may need to stage this from a much earlier rev of UHD. I don’t think
> there have been any updates to N210 firmware in a long time. So if you can
> tolerate UHD 3.15 that might be better for you.
>
> Sent from my iPhone
>
> On Nov 9, 2023, at 7:05 PM, German Farinas 
> wrote:
>
> 
> I am trying to upload the image to an usrp N210 rev2.0 but I got the
> following error message. Have anyone had the same error before? I need some
> help with this issue. See the output of the uhd_image_loader below.
>
> Best,
> German
>
> uhd_image_loader --args="type=usrp2,addr=192.168.10.2"
>
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
> UHD_4.5.0.0-0ubuntu1~focal1
> [ERROR] [UHD] Exception caught in safe-call.
>   in ~usrp2_iface_impl
>   at /build/uhd-UJYBdq/uhd-4.5.0.0/host/lib/usrp/usrp2/usrp2_iface.cpp:82
> this->lock_device(false); -> RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected protocol compatibility number [10 to 12], but got 9:
> The firmware build is not compatible with the host code build.
> Please run:
>
>  "/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
>  "/lib/bin/uhd_image_loader" \
> --args="type=usrp2,addr=192.168.10.2"
>
> Error: RuntimeError: Received invalid reply 32 from device.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] The firmware build is not compatible with the host code build

[German Farinas]

I am trying to upload the image to an usrp N210 rev2.0 but I got the
following error message. Have anyone had the same error before? I need some
help with this issue. See the output of the uhd_image_loader below.

Best,
German

uhd_image_loader --args="type=usrp2,addr=192.168.10.2"

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
UHD_4.5.0.0-0ubuntu1~focal1
[ERROR] [UHD] Exception caught in safe-call.
  in ~usrp2_iface_impl
  at /build/uhd-UJYBdq/uhd-4.5.0.0/host/lib/usrp/usrp2/usrp2_iface.cpp:82
this->lock_device(false); -> RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected protocol compatibility number [10 to 12], but got 9:
The firmware build is not compatible with the host code build.
Please run:

 "/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
 "/lib/bin/uhd_image_loader" \
--args="type=usrp2,addr=192.168.10.2"

Error: RuntimeError: Received invalid reply 32 from device.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2

[German Eichberger via dev]

+1

Heck, yeah, we already tested the branch (build ourselves) and it works great 
so far.

From: Mick Semb Wever 
Sent: Tuesday, October 31, 2023 1:43 PM
Cc: dev 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2

> 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
- signing correct
- checksums are correct
- source artefact builds (JDK 11+17)
- binary artefact runs (JDK 11+17)
- debian package runs (JDK 11+17)
- debian repo runs (JDK 11+17)
- redhat* package runs (JDK11+17)
- redhat* repo runs (JDK 11+17)

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[German Eichberger via dev]

Definitely want to second Josh. When I reached out on the ACCORD channel about 
testing folks were super helpful and transparent about bugs, etc.

Frankly, I was pretty frustrated that ACCORD+TCM slipped. I was looking forward 
to it and felt let down - but I also haven't done anything to help other than 
trying it out. So, I only have myself to blame...

That there was a surprise for many of us that it slipped is an indication there 
wasn't enough communication - we should probably rethink how we communicate 
progress, especially on long running and highly anticipated initiatives. Maybe 
a paragraph in the "Project Status Update" (but then we need more frequent 
updates ) -- or send a separate update e-mail or as Maxim is suggesting to 
some newly created release list.

A highly anticipated feature has more visibility and we need to account for 
that with more communication other than the usual channels. ACCORD in 
particular was hyped in numerous talks and presentations and noone cautioned it 
might not hit 5.0, quite the opposite --so we need to ask ourselves how people 
who go on stage as Cassandra experts are not aware that it could slip. That's 
where I think more communication could help --


Thanks,
German





From: Josh McKenzie 
Sent: Friday, October 27, 2023 10:13 AM
To: dev 
Subject: [EXTERNAL] Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut 
an immediate 5.1-alpha1)

Lots of threads of thought have popped up here. The big one I feel needs to be 
clearly addressed and inspected is the implication of development not happening 
transparently and not being inclusive or available for participation by the 
community on major features.

The CEP process + dedicated development channels on ASF slack + public JIRA's + 
feature branches in the ASF repo we've seen with specifically TCM and Accord 
are the most transparent this kind of development has ever been on this 
project, and I'd argue right at the sweet spot or past where the degree of 
reaching out to external parties to get feedback starts to not just hit 
diminishing returns but starts to actively hurt a small group of peoples' 
ability to make rapid progress on something.

No-one can expect to review everything, and no-one can expect to follow every 
JIRA, commit, or update. This is why we have the role of a committer; a person 
in this community we've publicly communicated we trust based on earned merit 
(and in our project's case, at least 2 people who's opinion we trust) to do 
quality work, validate it, and reach our expected bar for correctness, 
performance, and maintainability. If a CEP is voted in and 2 committers have an 
implementation they feel meets the goals, CI is green, and nobody has a serious 
technical concern that warrants a binding -1, we're good. It doesn't, and 
shouldn't, matter who currently employs or sponsors their work. It doesn't, and 
shouldn't, matter whether individuals on the project who were interested in 
collaborating on that work missed one or multiple announcements, or whether 
they saw those announcements and just didn't have the cycles to engage when 
they wanted to.

Now - we can always improve. We can always try and be proactive, knowing each 
other and our interests and reaching out to specific folks to make sure they're 
aware that work has hit a collaboration point or inflection point. I can do 
(apparently much) better about sending out more consistent project status 
updates with calls to action around when these inflection points occur as well.

At the end of the day, this is an Apache project, and trust and lazy consensus 
are the backbone for how a lot of this stuff works when distributed and at 
scale.

On Fri, Oct 27, 2023, at 10:51 AM, Alex Petrov wrote:
Firstly, when talking about quality, many folks mention the risk of releasing 
bugs together with TCM and Accord. While I agree this risk is real, I would 
like to remind that TCM and Accord were extensively tested and simulated, for 
many hours. Just an example, we’ve recently filed an issue we found during our 
Harry testing, and this issue was introduced outside TCM. So a lot of 
validation work will be invalidated by having two releases. And I am not 
certain how many organisations have capacity for internally vetting two 
subsequent major releases. But I am also not compeltely opposed to having 5.0 
and 5.1 if this is something a majority of contributors prefers.

As regards developing CEPs in public, this is how it was already done this 
time. Both Accord and TCM were published for a substantial amount of time. I 
did read an argument that the code was somehow not ready for review, but by the 
same logic neither is it ready right now, as the interesting parts haven't 
changed in a while. Even the feedback on the CEP itself, which was published in 
April 2023, was minimal. There were multiple sessions about the TCM and Accord 
in New Orleans in 2023, and the interested parties (incl

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[German Eichberger via dev]

+1 to Maxim's idea

Like Stefan my assumption was that we would get some version of TCM + ACCORD in 
5.0 but it wouldn't be ready for production use. My own testing and 
conversations at Community over Code in Halifax confirmed this.

From this perspective as disappointing as TCM+ACCORD slipping is moving it to 
5.1 makes sense and I am supporting of this - but I am worried if 5.1 is 
basically 5.0 + TCM/ACCORD and this slips again we draw ourselves into a corner 
where we can't release 5.2 before 5.1 or something. I would like some more 
elaboration on that.

I am also very worried about ANN vector search being in jeopardy for 5.0 which 
is an important feature for me to win some internal company bet 

My 2 cents,
German


From: Miklosovic, Stefan via dev 
Sent: Thursday, October 26, 2023 4:23 AM
To: dev@cassandra.apache.org 
Cc: Miklosovic, Stefan 
Subject: [EXTERNAL] Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut 
an immediate 5.1-alpha1)

What Maxim proposes in the last paragraph would be definitely helpful. Not for 
the project only but for a broader audience, companies etc., too.

Until this thread was started, my assumption was that "there will be 5.0 on 
summit with TCM and Accord and it somehow just happens". More transparent 
communication where we are at with high-profile CEPs like these and knowing if 
deadlines are going to be met would be welcome.

I don't want to be that guy and don't take me wrong here, but really, these 
CEPs are being developed, basically, by devs from two companies, which have 
developers who do not have any real need to explain themselves like what they 
do, regularly, to outsiders. (or maybe you do, you just don't have time?) I get 
that. But on the other hand, you can not realistically expect that other folks 
will have any visibility into what is going on there and that there is a delay 
on the horizon and so on.


From: Maxim Muzafarov 
Sent: Thursday, October 26, 2023 12:21
To: dev@cassandra.apache.org
Subject: Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 
5.1-alpha1)

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




Personally, I think frequent releases (2-3 per year) are better than
infrequent big releases. I can understand all the concerns from a
marketing perspective, as smaller major releases may not shine as
brightly as a single "game changer" release. However, smaller
releases, especially if they don't have backwards compatibility
issues, are better for the engineering and SRE teams because if a
long-awaited feature is delayed for any reason, there should be no
worry about getting it in right into the next release.

An analogy here might be that if you miss your train (small release)
due to circumstances, you can wait right here for the next one, but if
you miss a flight (big release), you will go back home :-) This is why
I think that the 5.0, 5.1, 5.2, etc. are better and I support Mick's
plan with the caveat that we should release 5.1 when we think we are
ready to do so. Here is an example of the Postgres releases [1].

[1] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbucardo.org%2Fpostgres_all_versions.html=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cc811f6a430d1466acc3f08dbd61639c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638339163187354112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=zjMpuN%2FQMhBtFTemLswn8BRaLyQ9eLZTIeZfeWYwhQk%3D=0<https://bucardo.org/postgres_all_versions.html>


Another little thing that I'd like to mention is a release management
story. In the Apache Ignite project, we've got used to creating a
release thread and posting the release status updates and/or problems,
and/or delays there, and maybe some of the benchmarks at the end. Of
course, this was done by the release manager who volunteered to do
this work. I'm not saying we're doing anything wrong here, no, but the
publicity and openness, coupled with regular updates, could help
create a real sense of the remaining work in progress. These are my
personal feelings, and definitely not actions to be taken. The example
is here: [2].

[2] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fm11m0nxq701f2cj8xxdcsc4nnn2sm8ql=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cc811f6a430d1466acc3f08dbd61639c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638339163187360611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BG0wgMItsMv83XDLzRgbfJoi%2FiwSywWU0qAzN%2BmMBZU%3D=0<https://lists.apache.org/thread/m11m0nxq701f2cj8xxdcsc4nnn2sm8ql>

On Thu, 26 Oct 2023 at 11:15, Benjamin Lerer  wrote:
>>
>> Regarding the release of 5.1, I understood the pr

Re: [FFmpeg-user] Why my cut video weighs twice as much?

[German Geraskin]

I tried to reproduce the issue, but had no troubles.
Perhaps there is something wrong with your INPUT file?

пн, 16 окт. 2023 г. в 10:48, Bohort :
>
> Hello,
> No one knows? :(
>
> Le sam. 14 oct. 2023 à 12:16, Bohort  a écrit :
>
> > Hi there,
> > I use version 4.4.2-0ubuntu0.22.04.1.
> > I want to cut a part of a video: to do this, I use ffmpeg, with these
> > options:
> > $ ffmpeg -i 2023-10-14.m2ts -ss 01:20:00.000 -to 01:30:36.300 -c:v copy
> > -c:a copy output.mp4
> > But I have some warnings/errors in the log (please see the attachment).
> > I wonder how to avoid it, if my options are wrong?
> > Or maybe it has been fixed in a new version that I haven't yet in my
> > system (I keep 22.04 because it's LTS, and will upgrade to 24.04 in a few
> > months)?
> > Thank you for your help.
> > B.
> >
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [Virtio-fs] [PATCH] virtiofs: Export filesystem tags through sysfs

[German Maglione]

On Tue, Oct 10, 2023 at 8:38 PM Stefan Hajnoczi  wrote:
>
> On Thu, Oct 05, 2023 at 04:30:30PM -0400, Vivek Goyal wrote:
> > virtiofs filesystem is mounted using a "tag" which is exported by the
> > virtiofs device. virtiofs driver knows about all the available tags but
> > these are not exported to user space.
> >
> > People have asked these tags to be exported to user space. Most recently
> > Lennart Poettering has asked for it as he wants to scan the tags and mount
> > virtiofs automatically in certain cases.
> >
> > https://gitlab.com/virtio-fs/virtiofsd/-/issues/128
> >
> > This patch exports tags through sysfs. One tag is associated with each
> > virtiofs device. A new "tag" file appears under virtiofs device dir.
> > Actual filesystem tag can be obtained by reading this "tag" file.
> >
> > For example, if a virtiofs device exports tag "myfs", a new file "tag"
> > will show up here.
> >
> > /sys/bus/virtio/devices/virtio/tag
> >
> > # cat /sys/bus/virtio/devices/virtio/tag
> > myfs
>
> If you respin this series, please mention that the tag is available at
> KOBJ_BIND time, but not KOBJ_ADD. Just a sentence or two is enough to
> help someone trying to figure out how to use this new sysfs attr with
> udev.

Maybe it's also worth mention, that the tag file is created after a successful
probe, so the tag should be a valid one: non-empty and unique

>
> >
> > Signed-off-by: Vivek Goyal 
> > ---
> >  fs/fuse/virtio_fs.c | 34 ++
> >  1 file changed, 34 insertions(+)
>
> Reviewed-by: Stefan Hajnoczi 



-- 
German

___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

Re: [Virtio-fs] (no subject)

[German Maglione]

On Tue, Oct 10, 2023 at 4:57 AM Yajun Wu  wrote:
>
>
> On 10/9/2023 6:28 PM, German Maglione wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Sat, Oct 7, 2023 at 4:23 AM Yajun Wu  wrote:
> >>
> >> On 10/6/2023 6:34 PM, Michael S. Tsirkin wrote:
> >>> External email: Use caution opening links or attachments
> >>>
> >>>
> >>> On Fri, Oct 06, 2023 at 11:47:55AM +0200, Hanna Czenczek wrote:
> >>>> On 06.10.23 11:26, Michael S. Tsirkin wrote:
> >>>>> On Fri, Oct 06, 2023 at 11:15:55AM +0200, Hanna Czenczek wrote:
> >>>>>> On 06.10.23 10:45, Michael S. Tsirkin wrote:
> >>>>>>> On Fri, Oct 06, 2023 at 09:48:14AM +0200, Hanna Czenczek wrote:
> >>>>>>>> On 05.10.23 19:15, Michael S. Tsirkin wrote:
> >>>>>>>>> On Thu, Oct 05, 2023 at 01:08:52PM -0400, Stefan Hajnoczi wrote:
> >>>>>>>>>> On Wed, Oct 04, 2023 at 02:58:57PM +0200, Hanna Czenczek wrote:
> >>>>>>>>>>> There is no clearly defined purpose for the virtio status byte in
> >>>>>>>>>>> vhost-user: For resetting, we already have RESET_DEVICE; and for 
> >>>>>>>>>>> virtio
> >>>>>>>>>>> feature negotiation, we have [GS]ET_FEATURES.  With the REPLY_ACK
> >>>>>>>>>>> protocol extension, it is possible for SET_FEATURES to return 
> >>>>>>>>>>> errors
> >>>>>>>>>>> (SET_PROTOCOL_FEATURES may be called before SET_FEATURES).
> >>>>>>>>>>>
> >>>>>>>>>>> As for implementations, SET_STATUS is not widely implemented.  
> >>>>>>>>>>> dpdk does
> >>>>>>>>>>> implement it, but only uses it to signal feature negotiation 
> >>>>>>>>>>> failure.
> >>>>>>>>>>> While it does log reset requests (SET_STATUS 0) as such, it 
> >>>>>>>>>>> effectively
> >>>>>>>>>>> ignores them, in contrast to RESET_OWNER (which is deprecated, 
> >>>>>>>>>>> and today
> >>>>>>>>>>> means the same thing as RESET_DEVICE).
> >>>>>>>>>>>
> >>>>>>>>>>> While qemu superficially has support for [GS]ET_STATUS, it does 
> >>>>>>>>>>> not
> >>>>>>>>>>> forward the guest-set status byte, but instead just makes it up
> >>>>>>>>>>> internally, and actually completely ignores what the back-end 
> >>>>>>>>>>> returns,
> >>>>>>>>>>> only using it as the template for a subsequent SET_STATUS to add 
> >>>>>>>>>>> single
> >>>>>>>>>>> bits to it.  Notably, after setting FEATURES_OK, it never reads 
> >>>>>>>>>>> it back
> >>>>>>>>>>> to see whether the flag is still set, which is the only way in 
> >>>>>>>>>>> which
> >>>>>>>>>>> dpdk uses the status byte.
> >>>>>>>>>>>
> >>>>>>>>>>> As-is, no front-end or back-end can rely on the other side 
> >>>>>>>>>>> handling this
> >>>>>>>>>>> field in a useful manner, and it also provides no practical use 
> >>>>>>>>>>> over
> >>>>>>>>>>> other mechanisms the vhost-user protocol has, which are more 
> >>>>>>>>>>> clearly
> >>>>>>>>>>> defined.  Deprecate it.
> >>>>>>>>>>>
> >>>>>>>>>>> Suggested-by: Stefan Hajnoczi 
> >>>>>>>>>>> Signed-off-by: Hanna Czenczek 
> >>>>>>>>>>> ---
> >>>>>>>>>>>   docs/interop/vhost-user.rst | 28 
> >>>>>>>>>>> +---
> >>>>>>>>>>>   1 file changed, 21 insertions(+), 7 deletions(-)
> >>>>>>>>>&g

Re: [Virtio-fs] (no subject)

[German Maglione]

On Tue, Oct 10, 2023 at 4:57 AM Yajun Wu  wrote:
>
>
> On 10/9/2023 6:28 PM, German Maglione wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Sat, Oct 7, 2023 at 4:23 AM Yajun Wu  wrote:
> >>
> >> On 10/6/2023 6:34 PM, Michael S. Tsirkin wrote:
> >>> External email: Use caution opening links or attachments
> >>>
> >>>
> >>> On Fri, Oct 06, 2023 at 11:47:55AM +0200, Hanna Czenczek wrote:
> >>>> On 06.10.23 11:26, Michael S. Tsirkin wrote:
> >>>>> On Fri, Oct 06, 2023 at 11:15:55AM +0200, Hanna Czenczek wrote:
> >>>>>> On 06.10.23 10:45, Michael S. Tsirkin wrote:
> >>>>>>> On Fri, Oct 06, 2023 at 09:48:14AM +0200, Hanna Czenczek wrote:
> >>>>>>>> On 05.10.23 19:15, Michael S. Tsirkin wrote:
> >>>>>>>>> On Thu, Oct 05, 2023 at 01:08:52PM -0400, Stefan Hajnoczi wrote:
> >>>>>>>>>> On Wed, Oct 04, 2023 at 02:58:57PM +0200, Hanna Czenczek wrote:
> >>>>>>>>>>> There is no clearly defined purpose for the virtio status byte in
> >>>>>>>>>>> vhost-user: For resetting, we already have RESET_DEVICE; and for 
> >>>>>>>>>>> virtio
> >>>>>>>>>>> feature negotiation, we have [GS]ET_FEATURES.  With the REPLY_ACK
> >>>>>>>>>>> protocol extension, it is possible for SET_FEATURES to return 
> >>>>>>>>>>> errors
> >>>>>>>>>>> (SET_PROTOCOL_FEATURES may be called before SET_FEATURES).
> >>>>>>>>>>>
> >>>>>>>>>>> As for implementations, SET_STATUS is not widely implemented.  
> >>>>>>>>>>> dpdk does
> >>>>>>>>>>> implement it, but only uses it to signal feature negotiation 
> >>>>>>>>>>> failure.
> >>>>>>>>>>> While it does log reset requests (SET_STATUS 0) as such, it 
> >>>>>>>>>>> effectively
> >>>>>>>>>>> ignores them, in contrast to RESET_OWNER (which is deprecated, 
> >>>>>>>>>>> and today
> >>>>>>>>>>> means the same thing as RESET_DEVICE).
> >>>>>>>>>>>
> >>>>>>>>>>> While qemu superficially has support for [GS]ET_STATUS, it does 
> >>>>>>>>>>> not
> >>>>>>>>>>> forward the guest-set status byte, but instead just makes it up
> >>>>>>>>>>> internally, and actually completely ignores what the back-end 
> >>>>>>>>>>> returns,
> >>>>>>>>>>> only using it as the template for a subsequent SET_STATUS to add 
> >>>>>>>>>>> single
> >>>>>>>>>>> bits to it.  Notably, after setting FEATURES_OK, it never reads 
> >>>>>>>>>>> it back
> >>>>>>>>>>> to see whether the flag is still set, which is the only way in 
> >>>>>>>>>>> which
> >>>>>>>>>>> dpdk uses the status byte.
> >>>>>>>>>>>
> >>>>>>>>>>> As-is, no front-end or back-end can rely on the other side 
> >>>>>>>>>>> handling this
> >>>>>>>>>>> field in a useful manner, and it also provides no practical use 
> >>>>>>>>>>> over
> >>>>>>>>>>> other mechanisms the vhost-user protocol has, which are more 
> >>>>>>>>>>> clearly
> >>>>>>>>>>> defined.  Deprecate it.
> >>>>>>>>>>>
> >>>>>>>>>>> Suggested-by: Stefan Hajnoczi 
> >>>>>>>>>>> Signed-off-by: Hanna Czenczek 
> >>>>>>>>>>> ---
> >>>>>>>>>>>   docs/interop/vhost-user.rst | 28 
> >>>>>>>>>>> +---
> >>>>>>>>>>>   1 file changed, 21 insertions(+), 7 deletions(-)
> >>>>>>>>>&g

Re: [Virtio-fs] (no subject)

[German Maglione]

 >>>>>>
> >>>>>> If not, the problem is that qemu has sent SET_STATUS 0 for a while 
> >>>>>> when the
> >>>>>> vCPUs are stopped, which generally seems to request a device reset.  
> >>>>>> If we
> >>>>>> don’t state at least that SET_STATUS 0 is to be ignored, back-ends 
> >>>>>> that will
> >>>>>> implement SET_STATUS later may break with at least these qemu 
> >>>>>> versions.  But
> >>>>>> documenting that a particular use of the status byte is to be ignored 
> >>>>>> would
> >>>>>> be really strange.
> >>>>>>
> >>>>>> Hanna
> >>>>> Hmm I guess. Though just following virtio spec seems cleaner to me...
> >>>>> vhost-user reconfigures the state fully on start.
> >>>> Not the internal device state, though.  virtiofsd has internal state, and
> >>>> other devices like vhost-gpu back-ends would probably, too.
> >>>>
> >>>> Stefan has recently sent a series
> >>>> (https://lists.nongnu.org/archive/html/qemu-devel/2023-10/msg00709.html) 
> >>>> to
> >>>> put the reset (RESET_DEVICE) into virtio_reset() (when we really need a
> >>>> reset).
> >>>>
> >>>> I really don’t like our current approach with the status byte. Following 
> >>>> the
> >>>> virtio specification to me would mean that the guest directly controls 
> >>>> this
> >>>> byte, which it does not.  qemu makes up values as it deems appropriate, 
> >>>> and
> >>>> this includes sending a SET_STATUS 0 when the guest is just paused, i.e.
> >>>> when the guest really doesn’t want a device reset.
> >>>>
> >>>> That means that qemu does not treat this as a virtio device field 
> >>>> (because
> >>>> that would mean exposing it to the guest driver), but instead treats it 
> >>>> as
> >>>> part of the vhost(-user) protocol.  It doesn’t feel right to me that we 
> >>>> use
> >>>> a virtio-defined feature for communication on the vhost level, i.e. 
> >>>> between
> >>>> front-end and back-end, and not between guest driver and device.  I think
> >>>> all vhost-level protocol features should be fully defined in the 
> >>>> vhost-user
> >>>> specification, which REPLY_ACK is.
> >>> Hmm that makes sense. Maybe we should have done what stefan's patch
> >>> is doing.
> >>>
> >>> Do look at the original commit that introduced it to understand why
> >>> it was added.
> >> I don’t understand why this was added to the stop/cont code, though.  If it
> >> is time consuming to make these changes, why are they done every time the 
> >> VM
> >> is paused
> >> and resumed?  It makes sense that this would be done for the initial
> >> configuration (where a reset also wouldn’t hurt), but here it seems wrong.
> >>
> >> (To be clear, a reset in the stop/cont code is wrong, because it breaks
> >> stateful devices.)
> >>
> >> Also, note the newer commits 6f8be29ec17 and c3716f260bf.  The reset as
> >> originally introduced was wrong even for non-stateful devices, because it
> >> occurred before we fetched the state (vring indices) so we could restore it
> >> later.  I don’t know how 923b8921d21 was tested, but if the back-end used
> >> for testing implemented SET_STATUS 0 as a reset, it could not have survived
> >> either migration or a stop/cont in general, because the vring indices would
> >> have been reset to 0.
> >>
> >> What I’m saying is, 923b8921d21 introduced SET_STATUS calls that broke all
> >> devices that would implement them as per virtio spec, and even today it’s
> >> broken for stateful devices.  The mentioned performance issue is likely
> >> real, but we can’t address it by making up SET_STATUS calls that are wrong.
> >>
> >> I concede that I didn’t think about DRIVER_OK.  Personally, I would do all
> >> final configuration that would happen upon a DRIVER_OK once the first vring
> >> is started (i.e. receives a kick).  That has the added benefit of being
> >> asynchronous because it doesn’t block any vhost-user messages (which are
> >> synchronous, and thus block downtime).
> >>
> >> Hanna
> >
> > For better or worse kick is per ring. It's out of spec to start rings
> > that were not kicked but I guess you could do configuration ...
> > Seems somewhat asymmetrical though.
> >
> > Let's wait until next week, hopefully Yajun Wu will answer.
> The main motivation of adding VHOST_USER_SET_STATUS is to let backend
> DPDK know
> when DRIVER_OK bit is valid. It's an indication of all VQ configuration
> has sent,
> otherwise DPDK has to rely on first queue pair is ready, then
> receiving/applying
> VQ configuration one by one.
>
> During live migration, configuring VQ one by one is very time consuming.
> For VIRTIO
> net vDPA, HW needs to know how many VQs are enabled to set
> RSS(Receive-Side Scaling).
>
> If you don’t want SET_STATUS message, backend can remove protocol
> feature bit
> VHOST_USER_PROTOCOL_F_STATUS.
> DPDK is ignoring SET_STATUS 0, but using GET_VRING_BASE to do device
> close/reset.

This is incorrect, resetting the device on GET_VRING_BASE breaks
the stop/cont. Since you don't want to reset the VQs on stop/cont.

>
> I'm not involved in discussion about adding SET_STATUS in Vhost
> protocol. This feature
> is essential for vDPA(same as vhost-vdpa implements VHOST_VDPA_SET_STATUS).
>
> Thanks,
> Yajun
> >
> >>>> Now, we could hand full control of the status byte to the guest, and that
> >>>> would make me content.  But I feel like that doesn’t really work, because
> >>>> qemu needs to intercept the status byte anyway (it needs to know when 
> >>>> there
> >>>> is a reset, probably wants to know when the device is configured, etc.), 
> >>>> so
> >>>> I don’t think having the status byte in vhost-user really gains us much 
> >>>> when
> >>>> qemu could translate status byte changes to/from other vhost-user 
> >>>> commands.
> >>>>
> >>>> Hanna
> >>> well it intercepts it but I think it could pass it on unchanged.
> >>>
> >>>
> >>>>> I guess symmetry was the
> >>>>> point. So I don't see why SET_STATUS 0 has to be ignored.
> >>>>>
> >>>>>
> >>>>> SET_STATUS was introduced by:
> >>>>>
> >>>>> commit 923b8921d210763359e96246a58658ac0db6c645
> >>>>> Author: Yajun Wu 
> >>>>> Date:   Mon Oct 17 14:44:52 2022 +0800
> >>>>>
> >>>>>vhost-user: Support vhost_dev_start
> >>>>>
> >>>>> CC the author.
> >>>>>
>
> ___
> Virtio-fs mailing list
> virtio...@redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs



-- 
German

Re: [Virtio-fs] (no subject)

[German Maglione]

 >>>>>>
> >>>>>> If not, the problem is that qemu has sent SET_STATUS 0 for a while 
> >>>>>> when the
> >>>>>> vCPUs are stopped, which generally seems to request a device reset.  
> >>>>>> If we
> >>>>>> don’t state at least that SET_STATUS 0 is to be ignored, back-ends 
> >>>>>> that will
> >>>>>> implement SET_STATUS later may break with at least these qemu 
> >>>>>> versions.  But
> >>>>>> documenting that a particular use of the status byte is to be ignored 
> >>>>>> would
> >>>>>> be really strange.
> >>>>>>
> >>>>>> Hanna
> >>>>> Hmm I guess. Though just following virtio spec seems cleaner to me...
> >>>>> vhost-user reconfigures the state fully on start.
> >>>> Not the internal device state, though.  virtiofsd has internal state, and
> >>>> other devices like vhost-gpu back-ends would probably, too.
> >>>>
> >>>> Stefan has recently sent a series
> >>>> (https://lists.nongnu.org/archive/html/qemu-devel/2023-10/msg00709.html) 
> >>>> to
> >>>> put the reset (RESET_DEVICE) into virtio_reset() (when we really need a
> >>>> reset).
> >>>>
> >>>> I really don’t like our current approach with the status byte. Following 
> >>>> the
> >>>> virtio specification to me would mean that the guest directly controls 
> >>>> this
> >>>> byte, which it does not.  qemu makes up values as it deems appropriate, 
> >>>> and
> >>>> this includes sending a SET_STATUS 0 when the guest is just paused, i.e.
> >>>> when the guest really doesn’t want a device reset.
> >>>>
> >>>> That means that qemu does not treat this as a virtio device field 
> >>>> (because
> >>>> that would mean exposing it to the guest driver), but instead treats it 
> >>>> as
> >>>> part of the vhost(-user) protocol.  It doesn’t feel right to me that we 
> >>>> use
> >>>> a virtio-defined feature for communication on the vhost level, i.e. 
> >>>> between
> >>>> front-end and back-end, and not between guest driver and device.  I think
> >>>> all vhost-level protocol features should be fully defined in the 
> >>>> vhost-user
> >>>> specification, which REPLY_ACK is.
> >>> Hmm that makes sense. Maybe we should have done what stefan's patch
> >>> is doing.
> >>>
> >>> Do look at the original commit that introduced it to understand why
> >>> it was added.
> >> I don’t understand why this was added to the stop/cont code, though.  If it
> >> is time consuming to make these changes, why are they done every time the 
> >> VM
> >> is paused
> >> and resumed?  It makes sense that this would be done for the initial
> >> configuration (where a reset also wouldn’t hurt), but here it seems wrong.
> >>
> >> (To be clear, a reset in the stop/cont code is wrong, because it breaks
> >> stateful devices.)
> >>
> >> Also, note the newer commits 6f8be29ec17 and c3716f260bf.  The reset as
> >> originally introduced was wrong even for non-stateful devices, because it
> >> occurred before we fetched the state (vring indices) so we could restore it
> >> later.  I don’t know how 923b8921d21 was tested, but if the back-end used
> >> for testing implemented SET_STATUS 0 as a reset, it could not have survived
> >> either migration or a stop/cont in general, because the vring indices would
> >> have been reset to 0.
> >>
> >> What I’m saying is, 923b8921d21 introduced SET_STATUS calls that broke all
> >> devices that would implement them as per virtio spec, and even today it’s
> >> broken for stateful devices.  The mentioned performance issue is likely
> >> real, but we can’t address it by making up SET_STATUS calls that are wrong.
> >>
> >> I concede that I didn’t think about DRIVER_OK.  Personally, I would do all
> >> final configuration that would happen upon a DRIVER_OK once the first vring
> >> is started (i.e. receives a kick).  That has the added benefit of being
> >> asynchronous because it doesn’t block any vhost-user messages (which are
> >> synchronous, and thus block downtime).
> >>
> >> Hanna
> >
> > For better or worse kick is per ring. It's out of spec to start rings
> > that were not kicked but I guess you could do configuration ...
> > Seems somewhat asymmetrical though.
> >
> > Let's wait until next week, hopefully Yajun Wu will answer.
> The main motivation of adding VHOST_USER_SET_STATUS is to let backend
> DPDK know
> when DRIVER_OK bit is valid. It's an indication of all VQ configuration
> has sent,
> otherwise DPDK has to rely on first queue pair is ready, then
> receiving/applying
> VQ configuration one by one.
>
> During live migration, configuring VQ one by one is very time consuming.
> For VIRTIO
> net vDPA, HW needs to know how many VQs are enabled to set
> RSS(Receive-Side Scaling).
>
> If you don’t want SET_STATUS message, backend can remove protocol
> feature bit
> VHOST_USER_PROTOCOL_F_STATUS.
> DPDK is ignoring SET_STATUS 0, but using GET_VRING_BASE to do device
> close/reset.

This is incorrect, resetting the device on GET_VRING_BASE breaks
the stop/cont. Since you don't want to reset the VQs on stop/cont.

>
> I'm not involved in discussion about adding SET_STATUS in Vhost
> protocol. This feature
> is essential for vDPA(same as vhost-vdpa implements VHOST_VDPA_SET_STATUS).
>
> Thanks,
> Yajun
> >
> >>>> Now, we could hand full control of the status byte to the guest, and that
> >>>> would make me content.  But I feel like that doesn’t really work, because
> >>>> qemu needs to intercept the status byte anyway (it needs to know when 
> >>>> there
> >>>> is a reset, probably wants to know when the device is configured, etc.), 
> >>>> so
> >>>> I don’t think having the status byte in vhost-user really gains us much 
> >>>> when
> >>>> qemu could translate status byte changes to/from other vhost-user 
> >>>> commands.
> >>>>
> >>>> Hanna
> >>> well it intercepts it but I think it could pass it on unchanged.
> >>>
> >>>
> >>>>> I guess symmetry was the
> >>>>> point. So I don't see why SET_STATUS 0 has to be ignored.
> >>>>>
> >>>>>
> >>>>> SET_STATUS was introduced by:
> >>>>>
> >>>>> commit 923b8921d210763359e96246a58658ac0db6c645
> >>>>> Author: Yajun Wu 
> >>>>> Date:   Mon Oct 17 14:44:52 2022 +0800
> >>>>>
> >>>>>vhost-user: Support vhost_dev_start
> >>>>>
> >>>>> CC the author.
> >>>>>
>
> ___
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs



-- 
German

___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

Hacktoberfest?

[German Eichberger via dev]

All,

It's that time of year where the Hacktoberfest happens 
again:https://hacktoberfest.com/participation/#maintainers

We would need to mark our repo and also review the contributions timely so the 
participants can earn their T-Shirt (?). As Ekaterina pointed out October is 
also the month were we are crunched for time due to the release but I wanted to 
bring this up to the community anyway to discuss.

Thanks,
German
[https://www.bing.com/th?id=OVP.sZvFxTzWLuCCxgiYyScldQEsCW=Api]<https://hacktoberfest.com/participation/#maintainers>
Participation | Hacktoberfest 
2023<https://hacktoberfest.com/participation/#maintainers>
Hacktoberfest: a month-long celebration of open-source projects, their 
maintainers, and the entire community of contributors.
hacktoberfest.com

[https://hacktoberfest.com/_next/static/media/opengraph.e5fafe07.png]<https://hacktoberfest.com/>
Hacktoberfest 2023<https://hacktoberfest.com/>
Hacktoberfest: a month-long celebration of open-source projects, their 
maintainers, and the entire community of contributors.
hacktoberfest.com

Re: [VOTE] Accept java-driver

[German Eichberger via dev]

+1

Really excited about this as well.

From: Mick Semb Wever 
Sent: Tuesday, October 3, 2023 2:16 AM
Cc: dev 
Subject: [EXTERNAL] Re: [VOTE] Accept java-driver



The vote will be open for 72 hours (or longer). Votes by PMC members are 
considered binding. A vote passes if there are at least three binding +1s and 
no -1's.


+1


… we will request ASF Infra to move the datastax/java-driver as-is to 
apache/java-driver


I see now this will likely be instead apache/cassandra-java-driver

Re: [FFmpeg-user] nvenc error

[German Geraskin]

> Hi I am using ffmpeg 4.3.2 with nvidia 470.42.01 cuda 11.4 but when i
> configure it to enable nvenc its always showing nvenc is requested but not
> configured what can i do to resolve this?
> ./configure --enable-cuvid --enable-nvenc --enable-nonfree --enable-gpl
> --enable-cuda --extra-cflags=-I/usr/local/cuda/include
> --extra-ldflags=-L/usr/local/cuda/lib64
> this is the command that i am using kindly help me to resolve this issue

You are trying to compile ffmpeg with support of nvenc (NVIDIA encoder).
If your machine has an NVIDIA card that has an encoder module then it
makes sense.

https://en.wikipedia.org/wiki/Nvidia_NVENC
https://developer.nvidia.com/ffmpeg

Start from this manual:
https://docs.nvidia.com/video-technologies/video-codec-sdk/12.0/ffmpeg-with-nvidia-gpu/index.html
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

[German Eichberger via dev]

Super excited about this as well. Happy to help test with Azure and any other 
way needed.

Thanks,
German

From: guo Maxwell 
Sent: Wednesday, September 27, 2023 7:38 PM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias 
external storage locations

Thanks , So I think a jira can be created now. And I'd be happy to provide some 
help with this as well if needed.

Henrik Ingo mailto:henrik.i...@datastax.com>> 
于2023年9月28日周四 00:21写道：
It seems I was volunteered to rebase the Astra implementation of this 
functionality (FileSystemProvider) onto Cassandra trunk. (And publish it, of 
course) I'll try to get going today or tomorrow, so that this  discussion can 
then benefit from having that code available for inspection. And potentially 
using it as a soluttion to this use case.

On Tue, Sep 26, 2023 at 8:04 PM Jake Luciani 
mailto:jak...@gmail.com>> wrote:
We (DataStax) have a FileSystemProvider for Astra we can provide.
Works with S3/GCS/Azure.

I'll ask someone on our end to make it accessible.

This would work by having a bucket prefix per node. But there are lots
of details needed to support things like out of bound compaction
(mentioned in CEP).

Jake

On Tue, Sep 26, 2023 at 12:56 PM Benedict 
mailto:bened...@apache.org>> wrote:
>
> I agree with Ariel, the more suitable insertion point is probably the JDK 
> level FileSystemProvider and FileSystem abstraction.
>
> It might also be that we can reuse existing work here in some cases?
>
> On 26 Sep 2023, at 17:49, Ariel Weisberg 
> mailto:ar...@weisberg.ws>> wrote:
>
> 
> Hi,
>
> Support for multiple storage backends including remote storage backends is a 
> pretty high value piece of functionality. I am happy to see there is interest 
> in that.
>
> I think that `ChannelProxyFactory` as an integration point is going to 
> quickly turn into a dead end as we get into really using multiple storage 
> backends. We need to be able to list files and really the full range of 
> filesystem interactions that Java supports should work with any backend to 
> make development, testing, and using existing code straightforward.
>
> It's a little more work to get C* to creates paths for alternate backends 
> where appropriate, but that works is probably necessary even with 
> `ChanelProxyFactory` and munging UNIX paths (vs supporting multiple 
> Fileystems). There will probably also be backend specific behaviors that show 
> up above the `ChannelProxy` layer that will depend on the backend.
>
> Ideally there would be some config to specify several backend filesystems and 
> their individual configuration that can be used, as well as configuration and 
> support for a "backend file router" for file creation (and opening) that can 
> be used to route files to the backend most appropriate.
>
> Regards,
> Ariel
>
> On Mon, Sep 25, 2023, at 2:48 AM, Claude Warren, Jr via dev wrote:
>
> I have just filed CEP-36 [1] to allow for keyspace/table storage outside of 
> the standard storage space.
>
> There are two desires  driving this change:
>
> The ability to temporarily move some keyspaces/tables to storage outside the 
> normal directory tree to other disk so that compaction can occur in 
> situations where there is not enough disk space for compaction and the 
> processing to the moved data can not be suspended.
> The ability to store infrequently used data on slower cheaper storage layers.
>
> I have a working POC implementation [2] though there are some issues still to 
> be solved and much logging to be reduced.
>
> I look forward to productive discussions,
> Claude
>
> [1] 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-36%3A+A+Configurable+ChannelProxy+to+alias+external+storage+locations
> [2] https://github.com/Claudenw/cassandra/tree/channel_proxy_factory
>
>
>


--
http://twitter.com/tjake


--

[https://lh5.googleusercontent.com/UwlCp-Ixn21QzYv9oNnaGy0cKfFk1ukEBVKSv4V3-nQShsR-cib_VeSuNm4M_xZxyAzTTr0Et7MsQuTDhUGcmWQyfVP801Flif-SGT2x38lFRGkgoMUB4cot1DB9xd7Y0x2P0wJWA-gQ5k4rzytFSoLCP4wJntmJzhlqTuQQsOanCBHeejtSBcBry5v6kw]

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com<http://www.datastax.com/>

[https://lh3.googleusercontent.com/T6MEp9neZySKd-eg-tkz96Yf4qG_Xsgu-IznDkdHfsHCjAnnHQP6OsPCdj8rsDvgKs-GJS6TA7Yx5HlK-zfRlE64j0zDpDG9cI29VaG948x5xLgUU4KKctaHNAhbpJ_pDwzRag9K7yCibGblB5Ix5z6Xj99Vc92V9nYSmR4HIj5F9T_TVI7ayW2n2_lp5Q]<https://www.facebook.com/datastax>
  
[https://lh3.googleusercontent.com/Xrju2UthJiMtMS5jFknV8AhVO45tfhXSR6U0F8Qam1Mu2taE2SeVcl5ExaxU5l6pG0fHjv2b6vvUOe12WQldMqsOHknC7wQtBVYiX9ff3fLMtFAbjVRM0MGTKvPsjAcMI_FNvcIcuWIBP_zwRuh3b3g6hjHOW0ik9bDPuuYMvdLWIF8C8YgKDYQ-nV9dlQ]
 <https://twitter.com/datastax>   
[https://lh5.googl

Re: man pages & info prefer HTML format

[Dennis German]

OK, ya learn something every day, at least I try to.

The documentation at
https://www.gnu.org/software/coreutils/manual/html_node/index.html
looks really good ! Examples and explanation.

Some extra begin/end quote (noise) and somewhat extra spacey with 
option  (multiple double spaced) on a separate line from the description.


From now on my goto reference.

Thanks for your replies.



@arsen: thanks for the reference to 
https://git.savannah.gnu.org/cgit/texinfo.git/tree/TODO.HTML


@berny: ... man pages are available online in HTML format: 
https://man7.org/linux/man-pages/


These pages are only partially in HTML format , not addressing:
#1 wrap text : They depend on  which prevents the user from 
adjusting for their required width.


#2  links: Example: You can read more about the GNU extensions to the 
DWARF standard /here/. here is not a link


#3a use BOTH color and less-than/greater-than .

#3b sometimes end up with confusing extra symbols for example in abidw:
• *--type-id-style 

Since very many people us a "multiple window" environment having a 
resizable, "slide_aroundable" web browser window on the same display, in 
another window, as a script source or command line makes easy viewing 
and reference.


With respect to ease of writing  the basic HTML tags are rather simple 
to write and then there is the write once read many,many times 
consideration.


@Dragan Simic: I'd like to understand why you feel that
" ability to view the source as-is, with no rendering applied"
is important


++++

On 9/24/23 08:37, Dennis German wrote:
After the  years and fine tuning of basic HTML, why aren't the man 
pages standardized to HTML format?


Perhaps some users don't frequently enough reference man pages as they 
should and fewer use info , but (nearly) everyone uses a browser.


And I don't mean programmatically simply wrapping the man page in HTML.

The ability to

     1) wrap text ( not truncate a line with a hyphen and place the
   last 4 or 5 characters on the next line) and let the user decide the
   width of the window

     2) embed links (rather than "see also")

     3) use basic fonts to render variables, command name, keywords,
   description and clarify optional and alternatives (rather than the
   noisy apostrophes, < and > which also take of space)

     4) show the user much more information the first and every page
   (rather than needing multiple lines for the simplest keyword
   description)

HTML is superior than the current format and easily customizable in 
width, font size and colors by the reader.


Thank you for your consideration,

Dennis German

man pages & info prefer HTML format

[Dennis German]

After the  years and fine tuning of basic HTML, why aren't the man pages 
standardized to HTML format?


Perhaps some users don't frequently enough reference man pages as they 
should and fewer use info , but (nearly) everyone uses a browser.


And I don't mean programmatically simply wrapping the man page in HTML.

The ability to

 1) wrap text ( not truncate a line with a hyphen and place the
   last 4 or 5 characters on the next line) and let the user decide the
   width of the window

 2) embed links (rather than "see also")

 3) use basic fonts to render variables, command name, keywords, 
   description and clarify optional and alternatives (rather than the
   noisy apostrophes, *<* and*>* which also take of space)

 4) show the user much more information the first and every page
   (rather than needing multiple lines for the simplest keyword
   description)

HTML is superior than the current format and easily customizable in 
width, font size and colors by the reader.


Thank you for your consideration,

Dennis German

Re: [EXTERNAL] Re: [DISCUSS] Add JVector as a dependency for CEP-30

[German Eichberger via dev]

+1 with taking it to legal

As anyone else I enjoy speculating about legal stuff and I think for jars you 
probably need possible deniability aka no paper trail that we knowingly... but 
that horse is out of the barn. So really interested in what legal says 

If you can stomach non Java here is an alternate DiskANN implementation: 
microsoft/DiskANN: Graph-structured Indices for Scalable, Fast, Fresh and 
Filtered Approximate Nearest Neighbor Search 
(github.com)<https://github.com/microsoft/DiskANN>

Thanks,
German


From: Josh McKenzie 
Sent: Friday, September 22, 2023 7:43 AM
To: dev 
Subject: [EXTERNAL] Re: [DISCUSS] Add JVector as a dependency for CEP-30

I highly doubt liability works like that in all jurisdictions
That's a fantastic point. When speculating there, I overlooked the fact that 
there are literally dozens of legal jurisdictions in which this project is used 
and the foundation operates.

As a PMC let's take this to legal.

On Fri, Sep 22, 2023, at 9:16 AM, Jeff Jirsa wrote:
To do that, the cassandra PMC can open a legal JIRA and ask for a (durable, 
concrete) opinion.


On Fri, Sep 22, 2023 at 5:59 AM Benedict 
mailto:bened...@apache.org>> wrote:


  1.  my understanding is that with the former the liability rests on the 
provider of the lib to ensure it's in compliance with their claims to copyright

I highly doubt liability works like that in all jurisdictions, even if it might 
in some. I can even think of some historic cases related to Linux where patent 
trolls went after users of Linux, though I’m not sure where that got to and I 
don’t remember all the details.

But anyway, none of us are lawyers and we shouldn’t be depending on this kind 
of analysis. At minimum we should invite legal to proffer an opinion on whether 
dependencies are a valid loophole to the policy.



On 22 Sep 2023, at 13:48, J. D. Jordan 
mailto:jeremiah.jor...@gmail.com>> wrote:


This Gen AI generated code use thread should probably be its own mailing list 
DISCUSS thread?  It applies to all source code we take in, and accept copyright 
assignment of, not to jars we depend on and not only to vector related code 
contributions.

On Sep 22, 2023, at 7:29 AM, Josh McKenzie 
mailto:jmcken...@apache.org>> wrote:

So if we're going to chat about GenAI on this thread here, 2 things:

  1.  A dependency we pull in != a code contribution (I am not a lawyer but my 
understanding is that with the former the liability rests on the provider of 
the lib to ensure it's in compliance with their claims to copyright and it's 
not sticky). Easier to transition to a different dep if there's something API 
compatible or similar.
  2.  With code contributions we take in, we take on some exposure in terms of 
copyright and infringement. git revert can be painful.

For this thread, here's an excerpt from the ASF policy:

a recommended practice when using generative AI tooling is to use tools with 
features that identify any included content that is similar to parts of the 
tool’s training data, as well as the license of that content.

Given the above, code generated in whole or in part using AI can be contributed 
if the contributor ensures that:

  1.  The terms and conditions of the generative AI tool do not place any 
restrictions on use of the output that would be inconsistent with the Open 
Source Definition (e.g., ChatGPT’s terms are inconsistent).
  2.
At least one of the following conditions is met:
 *   The output is not copyrightable subject matter (and would not be even 
if produced by a human)
 *   No third party materials are included in the output
 *   Any third party materials that are included in the output are being 
used with permission (e.g., under a compatible open source license) of the 
third party copyright holders and in compliance with the applicable license 
terms
  3.
A contributor obtain reasonable certainty that conditions 2.2 or 2.3 are met if 
the AI tool itself provides sufficient information about materials that may 
have been copied, or from code scanning results
 *   E.g. AWS CodeWhisperer recently added a feature that provides notice 
and attribution

When providing contributions authored using generative AI tooling, a 
recommended practice is for contributors to indicate the tooling used to create 
the contribution. This should be included as a token in the source control 
commit message, for example including the phrase “Generated-by

I think the real challenge right now is ensuring that the output from an LLM 
doesn't include a string of tokens that's identical to something in its input 
training dataset if it's trained on non-permissively licensed inputs. That plus 
the risk of, at least in the US, the courts landing on the side of saying that 
not only is the output of generative AI not copyrightable, but that there's 
legal liability on either the users of the tools or the creators of the models 
for some kind o

Re: [DISCUSS] Add JVector as a dependency for CEP-30

[German Eichberger via dev]

+1

I am biased because DiskANN is from Microsoft Research but it's  a good 
library/algorithm

From: Mike Adamson 
Sent: Wednesday, September 20, 2023 8:58 AM
To: dev 
Subject: [EXTERNAL] [DISCUSS] Add JVector as a dependency for CEP-30

You don't often get email from madam...@datastax.com. Learn why this is 
important
The original patch for CEP-30 brought several modified Lucene classes in-tree 
to implement the concurrent HNSW graph used by the vector index.

These classes are now being replaced with the io.github.jbellis.jvector 
library, which contains an improved diskANN implementation for the on-disk 
graph format.

The repo for this library is here: https://github.com/jbellis/jvector.

The library does not replace any code used by SAI or other parts of the 
codebase and is used solely by the vector index.

I would welcome any feedback on this change.
--
[DataStax Logo Square]   Mike Adamson
Engineering

+1 650 389 6000 | datastax.com
Find DataStax Online:   [LinkedIn Logo] 

[Facebook Logo] 

[Twitter Logo] [RSS Feed] 
[Github Logo] 

Re: [DISCUSS] Add Jepsen's Elle as a test dependency for Accord / Paxos

[German Eichberger via dev]

+1

From: David Capwell 
Sent: Wednesday, September 13, 2023 3:44 PM
To: dev 
Subject: [EXTERNAL] [DISCUSS] Add Jepsen's Elle as a test dependency for Accord 
/ Paxos

For validation of Paxos and Accord 2 different consistency verifiers were 
created: accord.verify.StrictSerializabilityVerifier (Accord), and 
org.apache.cassandra.simulator.paxos.LinearizabilityValidator (Paxos).  To 
increase confidence in both protocols it would be good to use an external 
consistency checker, such as Jepsen's Elle.

This work was first started in 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthe-asf.slack.com%2Farchives%2FC0459N9R5C6%2Fp1692192925909199=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf5c312fa94234393aac808dbb4ab03e1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638302418834282902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3MlXVG0bNQdj027o2E4fNTwOTygbPSkvhMzv7t4qRiU%3D=0
 by Jarek, and would be good to get as part of our automation.


https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjepsen-io%2Felle%2Fblob%2Fmain%2FLICENSE=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf5c312fa94234393aac808dbb4ab03e1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638302418834282902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lFu8RVB4FqoJ59FM5sqC3nTUYbgFsHZcDB6L2jgBgFM%3D=0
 - Eclipse Public License 2.0

Re: reggae v0.10.0 - The meta build system just got better

[German Diago via Digitalmars-d-announce]

On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves wrote:

https://code.dlang.org/packages/reggae

For those who don't know, reggae is a meta-build system for and 
in D. It's like CMake...


How mature is the build system? FWIW, I would like to stay in 
Meson if I can, since I use C++ also and that makes combining 
libs and other niceties easier.

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[German Eichberger via dev]

I concur. Those are major features...

From: C. Scott Andreas 
Sent: Friday, August 25, 2023 9:06 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha1

You don't often get email from sc...@paradoxica.net. Learn why this is 
important
A snapshot artifact seems more appropriate for early testing to me, rather than 
a voted / released build issued by the project given how much has yet to land.

- Scott

On Aug 25, 2023, at 8:46 AM, Ekaterina Dimitrova  wrote:


+1

On Fri, 25 Aug 2023 at 11:14, Mick Semb Wever 
mailto:m...@apache.org>> wrote:

Proposing the test build of Cassandra 5.0-alpha1 for release.

DISCLAIMER, this alpha release does not contain the expected 5.0
features: Vector Search (CEP-30), Transactional Cluster Metadata
(CEP-21) and Accord Transactions (CEP-15).  These features will land
in a later alpha release.

Please also note that this is an alpha release and what that means, further 
info at https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/

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]: CHANGES.txt: 
https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
[2]: NEWS.txt: 
https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt

Re: [Wien] SOC value \zeta

[Samolyuk, German D. via Wien]

Dear Gerhard,

Thank your for detailed answer.

If I understand it correctly the SOC part is introduced to the hamiltonian as

 (1)

following the expression for wave function phi (2.4 in the manual)
|phi_k(r)> = \sum_{L} [A_{L, k}u_L(r) + B_{L, k}{\dot u_L(r)}] Y_L

the expression (1) is naturally calculated as sum of four contributions and the 
first one has

\int dr u_L(r) \zeta u_L'(r). Again if I understand it correctly this integral 
is calculated in the code and it's the value I'm interested in.

Best,

German

Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)

From: Wien  on behalf of Fecher, 
Gerhard 
Sent: Friday, August 18, 2023 4:13 AM
To: A Mailing list for WIEN2k users 
Subject: [EXTERNAL] Re: [Wien] SOC value \zeta

Dear German,
as mentioned by Peter
https://urldefense.us/v2/url?u=https-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_msg09672.html=DwIGaQ=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=OsbEKiRMVyoB6JJ9cR0TBU0G3VtOXEqJhXaWmGQ8ribakT8R1LoQvMUNDI4mByuR=UIakgS3uhi68CwcKv4g46tpXC0-ZvZ8f_A2rVPjmMdM=
one may use the potential to estimate the spin-orbit coupling strength.
That is one may find the average of 1/r dV/dr by integration over space,
taking care that the potential is not spherical (as in a free atom) and thus 
depends not just on r but also on theta and phi.
(potential files from lapw0: spherical part: case.vsp and non-spherical part: 
case.vns., check the mesh and if they contain V or r*V !)
- Care has to be taken on the singularity at the nucleus (r=0) as mentioned 
previously, check r_0 !
- But which space do you take for the integration in case you have different 
atoms ?
  the muffin tin spheres or some Bader basins ?
  This is also the problem when 'estimating' so called site specific magnetic 
moments,
  the 'size' of the individual atoms in compounds is not known a priori  !

To calculate  you have to understand the wave functions in FPLAPW
as mentioned by Peter in
https://urldefense.us/v2/url?u=https-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_msg22739.html=DwIGaQ=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=OsbEKiRMVyoB6JJ9cR0TBU0G3VtOXEqJhXaWmGQ8ribakT8R1LoQvMUNDI4mByuR=wUyUKaXnqM6OAq2CDj8BVF5eGvoneLd5IH_t4pv1N_E=
Note that the wave functions (of the valence electrons) are k-dependent
This you see from the spin orbit splitting of the bands that depends on the 
direction in k-space.
Maybe you also think too much in atomic physics, where the spin orbit splitting 
does not depend k or any direction.

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Physics
Johannes Gutenberg - University
55099 Mainz

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Samolyuk, 
German D. via Wien [wien@zeus.theochem.tuwien.ac.at]
Gesendet: Donnerstag, 17. August 2023 17:43
An: A Mailing list for WIEN2k users
Cc: Samolyuk, German D.
Betreff: Re: [Wien] SOC value \zeta

Gerhard,

I wanted to know , i.e. part added to the hamiltonian 
resulting in eigenvalues and eigenvectors in case of added SOC and calculated 
using basis of wf obtained in no SOC case. The <(\sigma * l)> part I can 
calculate from density matrix output.

Gavin,

Thank you, the references help, but I'd rather don't hack the code .

Thank you,

German


Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)

From: Wien  on behalf of Fecher, 
Gerhard 
Sent: Thursday, August 17, 2023 2:23 AM
To: A Mailing list for WIEN2k users 
Subject: [EXTERNAL] Re: [Wien] SOC value \zeta

I don't understand the question,
what do you like to know, \zeta (proportional to 1/r dV/dr) for each atom or 
the orbital moment (m_l) for each atom ?

The r dependence tells you already that there is no single value for 'zeta = 
zeta(r)'
SO is calculated directly from dV/dr which is not printed somewhere, however 
for a pure Coulomb potential (Z/r) it depends on the ordinal number Z of the 
atom,
This explains why the spin orbit interaction is stronger for 'heavier' atoms.
|1/r dV/dr| becomes large in the vicinity of the nucleus (infinity at r=0) for 
all atoms.
This explains why the spin-orbit splitting is large for core level (the larger 
the closer they are (in average) to the nucleus) and small for semi-core or 
valence level, as these electrons are in average farer away from the nucleus.

C

Re: [Wien] SOC value \zeta

[Samolyuk, German D. via Wien]

Gerhard,

I wanted to know , i.e. part added to the hamiltonian 
resulting in eigenvalues and eigenvectors in case of added SOC and calculated 
using basis of wf obtained in no SOC case. The <(\sigma * l)> part I can 
calculate from density matrix output.

Gavin,

Thank you, the references help, but I'd rather don't hack the code .

Thank you,

German


Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)

From: Wien  on behalf of Fecher, 
Gerhard 
Sent: Thursday, August 17, 2023 2:23 AM
To: A Mailing list for WIEN2k users 
Subject: [EXTERNAL] Re: [Wien] SOC value \zeta

I don't understand the question,
what do you like to know, \zeta (proportional to 1/r dV/dr) for each atom or 
the orbital moment (m_l) for each atom ?

The r dependence tells you already that there is no single value for 'zeta = 
zeta(r)'
SO is calculated directly from dV/dr which is not printed somewhere, however 
for a pure Coulomb potential (Z/r) it depends on the ordinal number Z of the 
atom,
This explains why the spin orbit interaction is stronger for 'heavier' atoms.
|1/r dV/dr| becomes large in the vicinity of the nucleus (infinity at r=0) for 
all atoms.
This explains why the spin-orbit splitting is large for core level (the larger 
the closer they are (in average) to the nucleus) and small for semi-core or 
valence level, as these electrons are in average farer away from the nucleus.

Check the manual how to have the orbital moments printed.

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Physics
Johannes Gutenberg - University
55099 Mainz

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Samolyuk, 
German D. via Wien [wien@zeus.theochem.tuwien.ac.at]
Gesendet: Mittwoch, 16. August 2023 23:20
An: wien@zeus.theochem.tuwien.ac.at
Cc: Samolyuk, German D.
Betreff: [Wien] SOC value \zeta

Dear colleagues,

I'm running wien2k version WIEN2K_19_LI on linux cluster. The goal is to 
analyze magnetic anisotropy energy in YCo_5 intermetallic.

As it was explained in few presentation discussing SOC implementation in wien2K 
it's added in following form

\zeta ({\vec \sigma}{\vec l}), where \zeta = 1/(2Mc^2) 1/r^2 dV/dr.

Question: is it possible to output value \zeta for each atom, orbital moment?

I cant find it in output files and was not able to find following  discussion 
in archive.

Thank you,

German

Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
https://urldefense.us/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=Z0Ws7mNwi0HecEO8g8Ilg4oT94bzABn54RxNzgE074HCxT7FHLbZO1Ftr_ToxEk7=9cB8V56edYTJwbLsOWV0-mnAnnWV4nbLT4wVJ_fdEHk=
SEARCH the MAILING-LIST at:  
https://urldefense.us/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=lTD7jQRfMViWEsN8TZ1wLmkMhVe4MCRH76GADmGBpD4=Z0Ws7mNwi0HecEO8g8Ilg4oT94bzABn54RxNzgE074HCxT7FHLbZO1Ftr_ToxEk7=XsODSZtsVrEywDdUZ6HpsCkcXNxFS_VN93qPa5DEL3k=
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] SOC value \zeta

[Samolyuk, German D. via Wien]

Dear colleagues,

I'm running wien2k version WIEN2K_19_LI on linux cluster. The goal is to 
analyze magnetic anisotropy energy in YCo_5 intermetallic.

As it was explained in few presentation discussing SOC implementation in wien2K 
it's added in following form

\zeta ({\vec \sigma}{\vec l}), where \zeta = 1/(2Mc^2) 1/r^2 dV/dr.

Question: is it possible to output value \zeta for each atom, orbital moment?

I cant find it in output files and was not able to find following  discussion 
in archive.

Thank you,

German

Dr. German D Samolyuk
Materials Theory Group
Materials Science & Technology Division
Oak Ridge National Laboratory
Post Office Box 2008
Oak Ridge, TN 37831-6138
(865) 241-5394
(865) 241-3650 (FAX)
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [EXTERNAL] Re: [Discuss] ​​CEP-35: Add PIP support for CQLSH

[German Eichberger via dev]

I second Brandon. There is a group of people who expect to ssh into a node and 
then be able to run the "right" cqlsh instead of dealing with different cqlsh 
versions on their workstation/laptop...

German

From: Brandon Williams 
Sent: Friday, August 11, 2023 7:29 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [Discuss] ​​CEP-35: Add PIP support for CQLSH

On Fri, Aug 11, 2023 at 2:13 AM Miklosovic, Stefan
 wrote:
>
> If we had an official PIP package, I can imagine that we would not ship CQLSH 
> in RPM at all (maybe not in DEB either?) so we would decouple this. A PIP 
> package is installable almost anywhere (if it is Python 3, that is the way 
> how I solved the problem in 18642, I just installed a PIP package because RPM 
> installation was broken).

I don't think we want to ship the database without any way to interact
with it.  Pip may also not be accessible to all installations.

> Another problem I see is that how do we say what CQLSH is compatible with 
> what Cassandra release? If we shipped CQLSH as a PIP package as part of the 
> tarball, we would guarantee that they play together. If it is living 
> somewhere online, how can be people sure that what they install is compatible 
> with Cassandra they run? I am sorry if this was already explained somewhere.

It is only guaranteed to work with the version it shipped with. It may
work with other versions, or it may have subtle issues that you could
spend a lot of time trying to figure out, as German and I recently
discovered.  To that end, I've created CASSANDRA-18745 so at least you
will know to expect problems when the versions don't match.

Re: [Discuss] Repair inside C*

[German Eichberger via dev]

In [2] we suggested that the next step should be a CEP.

I am happy to lend a hand to this effort as well.

Thanks Jaydeep and David - really appreciated.

German


From: David Capwell 
Sent: Tuesday, July 25, 2023 8:32 AM
To: dev 
Cc: German Eichberger 
Subject: [EXTERNAL] Re: [Discuss] Repair inside C*

As someone who has done a lot of work trying to make repair stable, I approve 
of this message ^_^

More than glad to help mentor this work

On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia  
wrote:

To clarify the repair solution timing, the one we have listed in the article is 
not the recently developed one. We were hitting some high-priority production 
challenges back in early 2018, and to address that, we developed and rolled out 
the solution in production in just a few months. The timing-wise, the solution 
was developed and productized by Q3 2018, of course, continued to evolve 
thereafter. Usually, we explore the existing solutions we can leverage, but 
when we started our journey in early 2018, most of the solutions were based on 
sidecar solutions. There is nothing against the sidecar solution; it was just a 
pure business decision, and in that, we wanted to avoid the sidecar to avoid a 
dependency on the control plane. Every solution developed has its deep context, 
merits, and pros and cons; they are all great solutions!

An appeal to the community members is to think one more time about having 
repairs in the Open Source Cassandra itself. As mentioned in my previous email, 
any solution getting adopted is fine; the important aspect is to have a repair 
solution in the OSS Cassandra itself!

Yours Faithfully,
Jaydeep

On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia 
mailto:chovatia.jayd...@gmail.com>> wrote:
Hi German,

The goal is always to backport our learnings back to the community. For 
example, I have already successfully backported the following two 
enhancements/bug fixes back to the Open Source Cassandra, which are described 
in the article. I am already currently working on open-source a few more 
enhancements mentioned in the article back to the open-source.

  1.  https://issues.apache.org/jira/browse/CASSANDRA-18555
  2.  https://issues.apache.org/jira/browse/CASSANDRA-13740

There is definitely heavy interest in having the repair solution inside the 
Open Source Cassandra itself, very much like Compaction. As I write this email, 
we are internally working on a one-pager proposal doc to all the community 
members on having a repair inside the OSS Apache Cassandra along with our 
private fork - I will share it soon.

Generally, we are ok with any solution getting adopted (either Joey's solution 
or our repair solution or any other solution). The primary motivation is to 
have the repair embedded inside the open-source Cassandra itself, so we can 
retire all various privately developed solutions eventually :)

I am also happy to help (drive conversation, discussion, etc.) in any way to 
have a repair solution adopted inside Cassandra itself, please let me know. 
Happy to help!

Yours Faithfully,
Jaydeep

On Mon, Jul 24, 2023 at 1:44 PM German Eichberger via dev 
mailto:dev@cassandra.apache.org>> wrote:
All,

We had a brief discussion in [2] about the Uber article [1] where they talk 
about having integrated repair into Cassandra and how great that is. I 
expressed my disappointment that they didn't work with the community on that 
(Uber, if you are listening time to make amends ) and it turns out Joey 
already had the idea and wrote the code [3] - so I wanted to start a discussion 
to gauge interest and maybe how to revive that effort.

Thanks,
German

[1] https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/
[2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619
[3] https://issues.apache.org/jira/browse/CASSANDRA-14346

Re: [PATCH] virtio: Fix packed virtqueue used_idx mask

[German Maglione]

On Fri, Jul 21, 2023 at 3:51 PM Hanna Czenczek  wrote:
>
> virtio_queue_packed_set_last_avail_idx() is used by vhost devices to set
> the internal queue indices to what has been reported by the vhost
> back-end through GET_VRING_BASE.  For packed virtqueues, this
> 32-bit value is expected to contain both the device's internal avail and
> used indices, as well as their respective wrap counters.
>
> To get the used index, we shift the 32-bit value right by 16, and then
> apply a mask of 0x7.  That seems to be a typo, because it should be
> 0x7fff; first of all, the virtio specification says that the maximum
> queue size for packed virt queues is 2^15, so the indices cannot exceed
> 2^15 - 1 anyway, making 0x7fff the correct mask.  Second, the mask
> clearly is wrong from context, too, given that (A) `idx & 0x7` must
> be 0 at this point (`idx` is 32 bit and was shifted to the right by 16
> already), (B) `idx & 0x8000` is the used_wrap_counter, so should not be
> part of the used index, and (C) `vq->used_idx` is a `uint16_t`, so
> cannot fit the 0x7 part of the mask anyway.
>
> This most likely never produced any guest-visible bugs, though, because
> for a vhost device, qemu will probably not evaluate the used index
> outside of virtio_queue_packed_get_last_avail_idx(), where we
> reconstruct the 32-bit value from avail and used indices and their wrap
> counters again.  There, it does not matter whether the highest bit of
> the used_idx is the used index wrap counter, because we put the wrap
> counter exactly in that position anyway.
>
> Signed-off-by: Hanna Czenczek 
> ---
>  hw/virtio/virtio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 295a603e58..309038fd46 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -3321,7 +3321,7 @@ static void 
> virtio_queue_packed_set_last_avail_idx(VirtIODevice *vdev,
>  vq->last_avail_wrap_counter =
>  vq->shadow_avail_wrap_counter = !!(idx & 0x8000);
>  idx >>= 16;
> -vq->used_idx = idx & 0x7ffff;
> +vq->used_idx = idx & 0x7fff;
>  vq->used_wrap_counter = !!(idx & 0x8000);
>  }
>
> --
> 2.41.0
>
>

Reviewed-by: German Maglione 

-- 
German

Re: [PATCH] virtio: Fix packed virtqueue used_idx mask

[German Maglione]

On Fri, Jul 21, 2023 at 3:51 PM Hanna Czenczek  wrote:

> virtio_queue_packed_set_last_avail_idx() is used by vhost devices to set
> the internal queue indices to what has been reported by the vhost
> back-end through GET_VRING_BASE.  For packed virtqueues, this
> 32-bit value is expected to contain both the device's internal avail and
> used indices, as well as their respective wrap counters.
>
> To get the used index, we shift the 32-bit value right by 16, and then
> apply a mask of 0x7.  That seems to be a typo, because it should be
> 0x7fff; first of all, the virtio specification says that the maximum
> queue size for packed virt queues is 2^15, so the indices cannot exceed
> 2^15 - 1 anyway, making 0x7fff the correct mask.  Second, the mask
> clearly is wrong from context, too, given that (A) `idx & 0x7` must
> be 0 at this point (`idx` is 32 bit and was shifted to the right by 16
> already), (B) `idx & 0x8000` is the used_wrap_counter, so should not be
> part of the used index, and (C) `vq->used_idx` is a `uint16_t`, so
> cannot fit the 0x7 part of the mask anyway.
>
> This most likely never produced any guest-visible bugs, though, because
> for a vhost device, qemu will probably not evaluate the used index
> outside of virtio_queue_packed_get_last_avail_idx(), where we
> reconstruct the 32-bit value from avail and used indices and their wrap
> counters again.  There, it does not matter whether the highest bit of
> the used_idx is the used index wrap counter, because we put the wrap
> counter exactly in that position anyway.
>
> Signed-off-by: Hanna Czenczek 
> ---
>  hw/virtio/virtio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 295a603e58..309038fd46 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -3321,7 +3321,7 @@ static void
> virtio_queue_packed_set_last_avail_idx(VirtIODevice *vdev,
>  vq->last_avail_wrap_counter =
>  vq->shadow_avail_wrap_counter = !!(idx & 0x8000);
>  idx >>= 16;
> -vq->used_idx = idx & 0x7;
> +vq->used_idx = idx & 0x7fff;
>

isn't there a macro with this value?
or a macro that convert a number of bits in a mask?, something like:
#define BIT_MASK(n) (~(~0 << n))



>  vq->used_wrap_counter = !!(idx & 0x8000);
>  }
>
> --
> 2.41.0
>
>
>


-- 
German

[Discuss] Repair inside C*

[German Eichberger via dev]

All,

We had a brief discussion in [2] about the Uber article [1] where they talk 
about having integrated repair into Cassandra and how great that is. I 
expressed my disappointment that they didn't work with the community on that 
(Uber, if you are listening time to make amends ) and it turns out Joey 
already had the idea and wrote the code [3] - so I wanted to start a discussion 
to gauge interest and maybe how to revive that effort.

Thanks,
German

[1] https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/
[2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619
[3] https://issues.apache.org/jira/browse/CASSANDRA-14346

Re: [DISCUSS] Using ACCP or tc-native by default

[German Eichberger via dev]

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


From: Joseph Lynch 
Sent: Thursday, July 20, 2023 7:38 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default

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 default? If I recall correctly from the
messaging service patches (and zstd/lz4) it's reasonably
straightforward to try to load native code and then fail-back if you
fail.

-Joey

On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan  wrote:
>
> 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 there are probably multiple ways we could solve this without 
> requiring users to jump through a bunch of hoops?
> But I do agree we can’t make the project x86 only.
>
> -Jeremiah
>
> > On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
> >  wrote:
> >
> > 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
> >linux-x86_64
> > 
> >
> > Notice "classifier". That means that if we introduced this dependency into 
> > the project, what about ARM users? (there is corresponding aarch classifier 
> > as well). ACCP is platform-specific but we have to ship Cassandra 
> > platform-agnostic. It just needs to run OOTB everywhere. If we shipped that 
> > with x86 and a user runs Cassandra on ARM, I guess that would break things, 
> > right?
> >
> > We also can not just add both dependencies (both x86 and aarch) because how 
> > would we differentiate between them in runtime? That all is just too tricky 
> > / error prone.
> >
> > So, the approach we want to take is this:
> >
> > 1) nothing will be bundled in Cassandra by default
> > 2) a user is supposed to download the library and put it to the class path
> > 3) a user is supposed to put the implementation of ICryptoProvider 
> > interface Cassandra exposes to the class path
> > 3) a user is supposed to configure cassandra.yaml and its section 
> > "crypto_provider" to reference the implementation he wants
> >
> > That way, we avoid the situation when somebody runs x86 lib on ARM or vice 
> > versa.
> >
> > By default, NoOpProvider will be used, that means that the default crypto 
> > provider from JRE will be used.
> >
> > It can seem like we have not done too much progress here but hey ... we 
> > opened the project to the custom implementations of crypto providers a 
> > community can create. E.g. as 3rd party extensions etc ...
> >
> > I want to be sure that everybody is aware of this change (that we plan to 
> > do that in such a way that it will not be "bundled") and that everybody is 
> > on board with this. Otherwise I am all ears about how to do that 
> > differently.
> >
> > (1) 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-18624=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf4530a41df3b419fd2ff08db892f0ed6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638254607439254753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=kYGSZGi3caINvm%2FDT4ms3%2BrcnMTxg0E921cMjmUvHQw%3D=0<https://issues.apache.org/jira/browse/CASSANDRA-18624>
> >
> > 
> > From: German Eichberger via dev 
> > Sent: Friday, June 23, 2023 22:43
> > To: dev
> > Subject: Re: [DISCUSS] Using ACCP or tc-native by default
> >
> > NetApp Security WARNING: This is an external email. Do not click links or 
> > open attachments unless you recognize the sender and know the content is 
> > safe.
> >

[jira] [Commented] (CASSANDRA-18624) Make Corretto Crypto Provider the Default

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743309#comment-17743309
 ] 

German Eichberger commented on CASSANDRA-18624:
---

There is also a related proposal: 
https://issues.apache.org/jira/browse/CASSANDRA-15294

> Make Corretto Crypto Provider the Default
> -
>
> Key: CASSANDRA-18624
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18624
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Attachments: image.png
>
>
> [Amazon Corretto Crypto Provider| 
> https://github.com/corretto/amazon-corretto-crypto-provider] is an 
> alternative provider of TLS and cryptographic functions that has significant 
> performance benefits for Cassandra. It is Apache 2.0 licensed and has been 
> deployed in several existing large fleets. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18624) Make Corretto Crypto Provider the Default

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743307#comment-17743307
 ] 

German Eichberger commented on CASSANDRA-18624:
---

Clear logs would be helpful (e.g. the output of 
[corretto/amazon-corretto-crypto-provider: The Amazon Corretto Crypto Provider 
is a collection of high-performance cryptographic implementations exposed via 
standard JCA/JCE interfaces. 
(github.com)|https://github.com/corretto/amazon-corretto-crypto-provider#verification-optional]
 ) to know it works.

Also we would need some switch in case people want FIPS which is currently 
experimental in ACCP

> Make Corretto Crypto Provider the Default
> -
>
> Key: CASSANDRA-18624
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18624
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Dependencies
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Attachments: image.png
>
>
> [Amazon Corretto Crypto Provider| 
> https://github.com/corretto/amazon-corretto-crypto-provider] is an 
> alternative provider of TLS and cryptographic functions that has significant 
> performance benefits for Cassandra. It is Apache 2.0 licensed and has been 
> deployed in several existing large fleets. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: Changing the output of tooling between majors

[German Eichberger via dev]

+1 to always version the output format


From: Dinesh Joshi 
Sent: Thursday, July 13, 2023 3:36 PM
To: dev 
Subject: [EXTERNAL] Re: Changing the output of tooling between majors

This adds maintenance overhead but is a potential alternative. I would only 
flip the flag. I would prefer to make the default "legacy" output and innovate 
behind a "--output-format=v2" flag. That way tools do not break or have to 
change to pass in the new flag.

Ideally we should always version our output format - structured or not.

Dinesh

On Jul 13, 2023, at 9:08 AM, German Eichberger via dev 
 wrote:

Let's take this discussion in a different direction: If we add a --legacy 
​ argument where we are supporting an old version for those who 
need/want it but have the (breaking) changes on the default this feels like a 
compromise - and then we can deprecate the legacy format without impacting 
innovation. We can also flip this with requiring a flag for the changed format 
if we feel this is better.

This let's us innovate without breaking anyone. Thoughts?

Thanks,
German

Re: [Discuss] CQLSH confusion

[German Eichberger via dev]

Forgot the references:
[1] https://the-asf.slack.com/archives/CJZLTM05A/p1686771286554899
[2] https://issues.apache.org/jira/browse/CASSANDRA-18666

From: German Eichberger via dev 
Sent: Thursday, July 13, 2023 10:14 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] [Discuss] CQLSH confusion

All,

I am working with clusters with different Cassandra versions and have been 
using some cqlsh which "just worked". Recently I wanted to use virtual tables 
and ran into [1]. After that I filed [2].

Brandon states that "do not use a cqlsh that is from a different version than 
what is distributed with the server" since I have no idea what other 
incompatibilities like this there are, compatibility of that kind has never 
been a goal."

I would like to open the discussion if this is what we want: cqlsh needs to be 
in lockstep with the C* version.

Assuming, this is how things should be, I would propose to change the cqlsh 
versioning to be in line with the C* versioning. Right now I am using cqlsh 
6.0.1 and I have no idea to which C* version that translates to. Aligning 
versions would make this much easier.

Thanks,
German

[Discuss] CQLSH confusion

[German Eichberger via dev]

All,

I am working with clusters with different Cassandra versions and have been 
using some cqlsh which "just worked". Recently I wanted to use virtual tables 
and ran into [1]. After that I filed [2].

Brandon states that "do not use a cqlsh that is from a different version than 
what is distributed with the server" since I have no idea what other 
incompatibilities like this there are, compatibility of that kind has never 
been a goal."

I would like to open the discussion if this is what we want: cqlsh needs to be 
in lockstep with the C* version.

Assuming, this is how things should be, I would propose to change the cqlsh 
versioning to be in line with the C* versioning. Right now I am using cqlsh 
6.0.1 and I have no idea to which C* version that translates to. Aligning 
versions would make this much easier.

Thanks,
German

[jira] [Commented] (CASSANDRA-18666) [Doc] Add to virtual table documentation that a minimum cq;lsh version is needed

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742890#comment-17742890
 ] 

German Eichberger commented on CASSANDRA-18666:
---

That's fair. But if that's the case than cqlsh should have the same version as 
C* - what's this 6.1.0?

 

I work with C* clusters with different versions and so it's convenient to use 
*one* cqlsh - I found the older versions working well with newer Cassandra 
versions (except this virtual table thing) but I feel this is getting to a 
bigger scope and I should asks on the ML what we want...

> [Doc] Add to virtual table documentation that a minimum cq;lsh version is 
> needed
> 
>
> Key: CASSANDRA-18666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18666
> Project: Cassandra
>  Issue Type: New Feature
>    Reporter: German Eichberger
>Priority: Normal
>
> See [https://the-asf.slack.com/archives/CJZLTM05A/p1686771286554899] for 
> details.
>  
> Add some warning on top of 
> [https://cassandra.apache.org/doc/4.1/cassandra/new/virtualtables.html]  that 
> protocol version v5 is needed
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-18666) [Doc] Add to virtual table documentation that a minimum cq;lsh version is needed

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742876#comment-17742876
 ] 

German Eichberger commented on CASSANDRA-18666:
---

I know that cqlsh version 5.0.1 does not work while 6.1.0 does. So we can say 
if you want to use virtual tables you not only need to use cassandra 4.0 or 
later but also a cqlsh version later than 6.0? That would have helped me to 
troubleshoot quickly.

I was under the impression that virtual tables were implemented on the server 
and any cqlsh should be fine - since this is not the case I feel a Warning box 
spelling out the minimum version would be helpful. Also that it took weeks to 
get to the bottom is an indication that documentation is lacking.

> [Doc] Add to virtual table documentation that a minimum cq;lsh version is 
> needed
> 
>
> Key: CASSANDRA-18666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18666
> Project: Cassandra
>  Issue Type: New Feature
>    Reporter: German Eichberger
>Priority: Normal
>
> See [https://the-asf.slack.com/archives/CJZLTM05A/p1686771286554899] for 
> details.
>  
> Add some warning on top of 
> [https://cassandra.apache.org/doc/4.1/cassandra/new/virtualtables.html]  that 
> protocol version v5 is needed
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: Changing the output of tooling between majors

[German Eichberger via dev]

Let's take this discussion in a different direction: If we add a --legacy 
​ argument where we are supporting an old version for those who 
need/want it but have the (breaking) changes on the default this feels like a 
compromise - and then we can deprecate the legacy format without impacting 
innovation. We can also flip this with requiring a flag for the changed format 
if we feel this is better.

This let's us innovate without breaking anyone. Thoughts?

Thanks,
German


From: Miklosovic, Stefan 
Sent: Thursday, July 13, 2023 8:20 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: Changing the output of tooling between majors

"Dinesh's message cautions against making "breaking" changes that are likely to 
break parsing of output by current users (e.g., changes to naming/meaning/"

That is 100% correct. So by that logic, changing the output which you grep on 
to something else will break your scripts if you expect it there.

For example, take sstablemetadata command - I know it is not nodetool but it 
does not matter. This is just an example. Same "problem" can be found in 
nodetool probably, sstablemetadata just came to my mind first as that is what I 
hit recently.

sstablemetadata write this:

Repaired at: 0
Originating host id: d2d12c56-7d9c-49a7-aaef-05bd2633b09e
Pending repair: --
Replay positions covered: {CommitLogPosition(segmentId=1689261027905, 
position=59450)=CommitLogPosition(segmentId=1689261027905, position=60508)}
totalColumnsSet: 0
totalRows: 1
Estimated tombstone drop times:


Do you see "totalColumsSet" and "totalRows" when all other keys in that ouput 
(in whole command) are following different format? In this case, it should be 
"Total columns set" and "Total rows".

So when we change it to that, anybody who is grepping "totalRows" will have no 
output. That is a breaking change to me. His script stopped to work.

You are correct and I agree with you completely that STRICT ADDITIONS (what I 
was suggesting) are fine because we are not breaking anything to anybody.

So here, if I want to change this, by what Dinesh says, (we change the naming 
and we break it), I need to offer JSON / YAML alternative to what 
sstablemetadata prints currently. (might be as well nodetool, just an example).


From: C. Scott Andreas 
Sent: Thursday, July 13, 2023 17:01
To: dev@cassandra.apache.org
Cc: dev@cassandra.apache.org
Subject: Re: Changing the output of tooling between majors

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



Dinesh's message cautions against making "breaking" changes that are likely to 
break parsing of output by current users (e.g., changes to 
naming/meaning/position of existing fields vs. adding new ones). I don't read 
his message as saying that any change to nodetool output is conditional on 
offering a JSON/YAML representation, though.

What are some changes that you'd like to make?

– Scott

On Jul 13, 2023, at 7:44 AM, "Miklosovic, Stefan" 
 wrote:


For example Dinesh said this:

"Until nodetool can support JSON as output format for all interaction and there 
is a significant adoption in the user community, I would strongly advise 
against making breaking changes to the CLI output."

That is where I get the need to have a JSON output in order to fix a typo from. 
That is if we look at fixing a typo as a breaking change. Which I would say it 
is as if somebody is "greping" it and it is not there, it will break.

Do you understand that the same way or am I interpreting that wrong?


From: C. Scott Andreas 
Sent: Thursday, July 13, 2023 16:35
To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>
Cc: dev
Subject: Re: Changing the output of tooling between majors

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



"From what I see you guys want to condition any change by offering json/yaml as 
well."

I don't think I've seen a proposal to block changes to nodetool output on 
machine-parseable formats in this thread.

Additions of new delimited fields to nodetool output are mostly 
straightforward. Changes to fields that exist today are likely to cause 
problems - as Josh mentions. These seem best to take on a case-by-case basis 
rather than trying to hammer out an abstract policy. What changes would you 
like to make?

I do think we will have difficulty evolving output formats of text-based 
Cassandra tooling until we offer machine-parseable output formats.

– Scott

On Jul 13, 2023, at 6:39 AM, Josh McKenzie  wrote:


I just find it ridiculous we can not change "someProperty: 10" to &quo

[jira] [Commented] (CASSANDRA-18666) [Doc] Add to virtual table documentation that a minimum cq;lsh version is needed

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742847#comment-17742847
 ] 

German Eichberger commented on CASSANDRA-18666:
---

Thanks I didn't debug further after it worked. But that there is so much 
confusion makes this a good candidate for additional documentation.

> [Doc] Add to virtual table documentation that a minimum cq;lsh version is 
> needed
> 
>
> Key: CASSANDRA-18666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18666
> Project: Cassandra
>  Issue Type: New Feature
>    Reporter: German Eichberger
>Priority: Normal
>
> See [https://the-asf.slack.com/archives/CJZLTM05A/p1686771286554899] for 
> details.
>  
> Add some warning on top of 
> [https://cassandra.apache.org/doc/4.1/cassandra/new/virtualtables.html]  that 
> protocol version v5 is needed
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-18666) [Doc] Add to virtual table documentation that a minimum cq;lsh version is needed

[German Eichberger (Jira)]

German Eichberger created CASSANDRA-18666:
-

 Summary: [Doc] Add to virtual table documentation that a minimum 
cq;lsh version is needed
 Key: CASSANDRA-18666
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18666
 Project: Cassandra
  Issue Type: New Feature
Reporter: German Eichberger


See [https://the-asf.slack.com/archives/CJZLTM05A/p1686771286554899] for 
details.

 

Add some warning on top of 
[https://cassandra.apache.org/doc/4.1/cassandra/new/virtualtables.html]  that 
protocol version v5 is needed

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [DISCUSS] Conducting a User Survey

[German Eichberger]

Same. Great idea. How ill the results be published?

Thanks,
German

From: C. Scott Andreas 
Sent: Tuesday, July 11, 2023 7:41 AM
To: d...@cassandra.apache.org 
Cc: d...@cassandra.apache.org ; 
marketing@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] Conducting a User Survey

Thanks Patrick. I like the idea of a user survey.

Added a handful of comments in the doc. 

– Scott

On Jul 11, 2023, at 12:51 AM, Mick Semb Wever  wrote:


Looks good to me, thanks Patrick.

On Tue, 11 Jul 2023 at 03:11, Patrick McFadin  wrote:

For quite a few years, I have done Twitter polls to gather helpful information 
about how people use Apache Cassandra. Twitter is no longer the best place to 
conduct this kind of activity since it has become a ghost town.

We should ask more comprehensive questions to get the pulse of our user 
community. I want to do a simple Google Form survey that we can promote on 
every channel for a few weeks. I'll anonymize the results and post them on 
cassandra.apache.org.

Here are the proposed questions I have compiled. A pretty basic set of 
questions, but it would be fun to know the answer to several of these: 
https://docs.google.com/document/d/18627E1UV-BjLyuNFgV0cgPwPmtjUHy7Th9Mk15ll1IA/edit?usp=sharing

Comments are open to all. Please let me know what you think.

Patrick

Re: [DISCUSS] Conducting a User Survey

[German Eichberger via dev]

Same. Great idea. How ill the results be published?

Thanks,
German

From: C. Scott Andreas 
Sent: Tuesday, July 11, 2023 7:41 AM
To: dev@cassandra.apache.org 
Cc: dev@cassandra.apache.org ; 
market...@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] Conducting a User Survey

Thanks Patrick. I like the idea of a user survey.

Added a handful of comments in the doc. 

– Scott

On Jul 11, 2023, at 12:51 AM, Mick Semb Wever  wrote:


Looks good to me, thanks Patrick.

On Tue, 11 Jul 2023 at 03:11, Patrick McFadin  wrote:

For quite a few years, I have done Twitter polls to gather helpful information 
about how people use Apache Cassandra. Twitter is no longer the best place to 
conduct this kind of activity since it has become a ghost town.

We should ask more comprehensive questions to get the pulse of our user 
community. I want to do a simple Google Form survey that we can promote on 
every channel for a few weeks. I'll anonymize the results and post them on 
cassandra.apache.org.

Here are the proposed questions I have compiled. A pretty basic set of 
questions, but it would be fun to know the answer to several of these: 
https://docs.google.com/document/d/18627E1UV-BjLyuNFgV0cgPwPmtjUHy7Th9Mk15ll1IA/edit?usp=sharing

Comments are open to all. Please let me know what you think.

Patrick

Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of the release process

[German Eichberger via dev]

Same - really appreciate those efforts and also welcome the upstreaming and 
release automation...

German

From: Jeff Widman 
Sent: Sunday, July 9, 2023 1:44 PM
To: Max C. 
Cc: dev@cassandra.apache.org ; Brad Schoening 

Subject: [EXTERNAL] Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as 
part of the release process

You don't often get email from j...@jeffwidman.com. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Thanks Max, always encouraging to hear that the time I spend on open source is 
helping others.

Your use case is very similar to what drove my original desire to get involved 
with the project. Being able to `pip install cqlsh` from a dev machine was so 
much lighter weight than the alternatives.

Anyone else care to weigh in on this?

What are the next steps to move to a decision?

Cheers,
Jeff

On Sat, Jul 8, 2023, 7:23 PM Max C. 
mailto:mc_cassand...@core43.com>> wrote:

As a user, I really appreciate your efforts Jeff & Brad.  I would *love* for 
the C* project to officially support this.

In our environment we have a lot of client machines that all share common NFS 
mounted directories.  It's much easier for us to create a Python virtual 
environment on a file server with the cqlsh PyPI package installed than it is 
to install the Cassandra RPMs on every single machine.  Before I discovered 
your PyPI package, our developers would need to login to  a Cassandra node in 
order to run cqlsh.  The cqlsh PyPI package, however, is in our standard 
"python dev tools" virtual environment -- along with Ansible, black, isort and 
various other Python packages; which means it's accessible to everyone, 
everywhere.

I agree that this should not replace packaging cqlsh in the Cassandra RPM, so 
much provide an additional option for installing cqlsh without the baggage of 
installing the full Cassandra package.

Thanks again for your work Jeff & Brad.

- Max

On 7/6/2023 5:55 PM, Jeff Widman wrote:
Myself and Brad Schoening currently maintain https://pypi.org/project/cqlsh/ 
which repackages CQLSH that ships with every Cassandra release.

This way:

  *   anyone who wants a lightweight client to talk to a remote cassandra can 
simply `pip install cqlsh` without having to download the full cassandra 
source, unzip it, etc.
  *   it's very easy for folks to use it as scaffolding in their python 
scripts/tooling since they can simply include it in the list of their required 
dependencies.

We currently handle the packaging by waiting for a release, then manually 
copy/pasting the code out of the cassandra source tree into 
https://github.com/jeffwidman/cqlsh which has some additional build/python 
package configuration files, then using standard python tooling to publish to 
PyPI.

Given that our project is simply a build/packaging project, I wanted to start a 
conversation about upstreaming this into core Cassandra. I realize that 
Cassandra has no interest in maintaining lots of build targets... but given 
that cqlsh is written in Python and publishing to PyPI enables DBA's to share 
more complicated tooling built on top of it this seems like a natural fit for 
core cassandra rather than a standalone project.

Goal:
When a Cassandra release happens, the build/release process automatically 
publishes cqlsh to https://pypi.org/project/cqlsh/.

Non-Goal: This is _not_ about having cassandra itself rely on PyPI. There was 
some initial chatter about that in 
https://issues.apache.org/jira/browse/CASSANDRA-18654, but that adds a lot of 
complexity, and I'm honestly not sure it's a great idea. Even if folks later 
want to go that route, the first hurdle is publishing to PyPI, so for now let's 
keep the scope of the discussion limited to treating PyPI purely as a release 
target, and not as an ingredient to a release.

>From an implementation perspective, this should be very straightforward. We 
>don't have any differences from the CQLSH source that's in cassandra, instead 
>we point folks to make changes to cqlsh in the Cassandra source. In fact we've 
>made multiple contributions back to `cqlsh` ourselves and have drastically 
>cleaned up the code: 
>https://github.com/search?q=repo%3Aapache%2Fcassandra%20is%3Apr%20author%3Ajeffwidman%20author%3Abschoening=pullrequests.
> So the only real change is adding the package config files and the build / 
>release pipeline.

We realize the Cassandra team isn't python/PyPI experts, so we'd be more than 
happy to help wire this up and maintain it. I am also a maintainer of kazoo and 
kafka-python which are both popular python clients for other distributed 
databases. So I'm very familiar with open source, python, and distributed 
databases.

My one hesitation around this discussion is that I'm a little concerned that we 
might lose the nimbleness we've currently got from having a separate project. 
Ie, if something is screwed up on PyPI / the bui

[jira] [Commented] (CASSANDRA-18646) Create Azure snitch

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739494#comment-17739494
 ] 

German Eichberger commented on CASSANDRA-18646:
---

I am off this week but alerted the few people remaining in the office -

On Mon, Jul 3, 2023 at 9:41 AM Stefan Miklosovic (Jira) 



> Create Azure snitch
> ---
>
> Key: CASSANDRA-18646
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18646
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Stefan Miklosovic
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Create Azure snitch to support Azure clouds.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[kwin] [Bug 469198] Cursor shadow glitch

[German P]

https://bugs.kde.org/show_bug.cgi?id=469198

--- Comment #5 from German P  ---
(In reply to winblocker from comment #3)
> This most likely is related to software cursors (KWIN_FORCE_SW_CURSOR=1). I
> can reproduce this by hovering over his attachment link in comment #1 within
> Firefox.

Setting or unsetting that variable does nothing in my case.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 469198] Cursor shadow glitch

[German P]

https://bugs.kde.org/show_bug.cgi?id=469198

--- Comment #4 from German P  ---
(In reply to Nate Graham from comment #2)
> What kind of GPU are you using?

Sorry for the delay. It's an Nvidia GTX960.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 471525] New: [KICKOFF] Discover can't be removed from favorites

[German P]

https://bugs.kde.org/show_bug.cgi?id=471525

Bug ID: 471525
   Summary: [KICKOFF] Discover can't be removed from favorites
Classification: Plasma
   Product: plasmashell
   Version: 5.27.6
  Platform: Manjaro
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Application Launcher (Kickoff)
  Assignee: plasma-b...@kde.org
  Reporter: german...@hotmail.com
CC: mikel5...@gmail.com, noaha...@gmail.com
  Target Milestone: 1.0

Steps:
Remove discover from Kickoff favorites list
Restart plasmashell

Result:
Discover icon reapears.

Same as closed bug 385814

SOFTWARE/OS VERSIONS
Manjaro testing linux 6.4.0
Plasma 5.27.6 (Wayland)
KDE Frameworks 5.107.0
QT 5.15.10

-- 
You are receiving this mail because:
You are watching all bug changes.

[jira] [Commented] (CASSANDRA-18438) Refactor the code for public cloud platform snitch to be configurable

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737176#comment-17737176
 ] 

German Eichberger commented on CASSANDRA-18438:
---

Agree with [~smiklosovic]  that we should code this in Java rather than come up 
with some endpoint/regex/etc. in yaml. That said I am watching this with 
interest so I can write an Azure snitch.

> Refactor the code for public cloud platform snitch to be configurable
> -
>
> Key: CASSANDRA-18438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18438
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Other
>Reporter: Maxwell Guo
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
>
> Nowadays we have got about four public cloud platform snitchs ： EC2 snitch 
> for aws, google cloud snitch for google cloud, alibaba cloud snitch for 
> alibaba cloud and multi region snitch for ec2. And the common place for the 
> first three is that we just need to query the zone center to get the ec2 / 
> ecs id , so I think we can refactor the code , and  if some new public cloud 
> platform want to add one more snitch for himself, there is no need to pull a 
> pr for him and  configure some options in yaml is enough .
> Besides it would be even better that we may reuse the multic region snitch 
> for ec2 for other public cloud platform.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [DISCUSS] Using ACCP or tc-native by default

[German Eichberger via dev]

+1 to ACCP - we love performance.

From: David Capwell 
Sent: Thursday, June 22, 2023 4:21 PM
To: dev 
Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default

+1 to ACCP

On Jun 22, 2023, at 3:05 PM, C. Scott Andreas  wrote:

+1 for ACCP and can attest to its results. ACCP also optimizes for a range of 
hash functions and other cryptographic primitives beyond TLS acceleration for 
Netty.

On Jun 22, 2023, at 2:07 PM, Jeff Jirsa  wrote:


Either would be better than today.

On Thu, Jun 22, 2023 at 1:57 PM Jordan West 
mailto:jw...@apache.org>> wrote:
Hi,

I’m wondering if there is appetite to change the default SSL provider for 
Cassandra going forward to either ACCP [1] or tc-native in Netty? Our 
deployment as well as others I’m aware of make this change in their fork and it 
can lead to significant performance improvement. When recently qualifying 4.1 
without using ACCP (by accident) we noticed p99 latencies were 2x higher than 
3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and also requires some 
amount of customization. I think it could be great for the wider community to 
adopt it.

The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed. 
Anything else I am missing before opening a JIRA and submitting a patch?

Jordan


[1]
https://github.com/corretto/amazon-corretto-crypto-provider

Re: [VOTE] CEP-8 Datastax Drivers Donation

[German Eichberger via dev]

+ 1

Great to see this moving forward!

From: Abe Ratnofsky 
Sent: Tuesday, June 13, 2023 10:09 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] CEP-8 Datastax Drivers Donation

+1 (nb)

On Jun 13, 2023, at 09:23, Andrés de la Peña  wrote:


+1

On Tue, 13 Jun 2023 at 16:40, Yifan Cai 
mailto:yc25c...@gmail.com>> wrote:
+1

From: David Capwell mailto:dcapw...@apple.com>>
Sent: Tuesday, June 13, 2023 8:37:10 AM
To: dev mailto:dev@cassandra.apache.org>>
Subject: Re: [VOTE] CEP-8 Datastax Drivers Donation

+1

On Jun 13, 2023, at 7:59 AM, Josh McKenzie 
mailto:jmcken...@apache.org>> wrote:

+1

On Tue, Jun 13, 2023, at 10:55 AM, Jeremiah Jordan wrote:
+1 nb

On Jun 13, 2023 at 9:14:35 AM, Jeremy Hanna 
mailto:jeremy.hanna1...@gmail.com>> 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 drivers, one by one. Each driver donation will 
need to be accepted first by the PMC members, as it is the case for any 
donation. Therefore the PMC should have full control on the pace at which new 
drivers are accepted.

If this vote passes, we can start this process for the Java driver under the 
direction of the PMC.

Jeremy

1. 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp

Re:

[German Cardozo]

or details.
Do you want to accept these changes and continue updating from this
repository? [y/N] y
Get:6 http://ftp.us.debian.org/debian testing/main Sources.diff/Index
[740 B]
Get:7 http://ftp.us.debian.org/debian testing/main Sources
2023-06-11-0934.16.pdiff [49 B]
Get:7 http://ftp.us.debian.org/debian testing/main Sources
2023-06-11-0934.16.pdiff [49 B]
Fetched 207 kB in 28s (7,330 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done

### /etc/apt/sources.list (después)
deb http://ftp.us.debian.org/debian/ testing main non-free
non-free-firmware contrib
deb-src http://ftp.us.debian.org/debian/ testing main non-free
non-free-firmware contrib

deb http://security.debian.org/debian-security testing-security main
contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security testing-security
main contrib non-free non-free-firmware

# testing-updates, to get updates before a point release is made;
# see 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://ftp.us.debian.org/debian/ testing-updates main contrib
non-free non-free-firmware
deb-src http://ftp.us.debian.org/debian/ testing-updates main contrib
non-free non-free-firmware

Quiero pensar que no es más que una notificación del cambio del
repositorio testing de _bookworm_ a _trixie_.

Si persiste el error, sigue el procedimiento para actualizar el
/etc/apt/sources.list a _trixie_ , o  preferiblemente a _testing_ como
indica https://wiki.debian.org/DebianTesting .

Saludos,

German Cardozo Chirinos
~ memento mori ~

:wq!

[jira] [Commented] (CASSANDRA-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730293#comment-17730293
 ] 

German Eichberger commented on CASSANDRA-18575:
---

[[CASSANDRA-18575] Backport remove hard-coded SSL cipher suites and protocols 
by xgerman · Pull Request #2397 · apache/cassandra 
(github.com)|https://github.com/apache/cassandra/pull/2397]

> Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
> --
>
> Key: CASSANDRA-18575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18575
> Project: Cassandra
>  Issue Type: Bug
>Reporter: German Eichberger
>    Assignee: German Eichberger
>Priority: Normal
>
> Cassandra 3.0 has ciphers hard coded and thus not allow more recent and 
> secure ciphers for gossip connections complicating migrations to later 
> versions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Assigned] (CASSANDRA-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols

[German Eichberger (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

German Eichberger reassigned CASSANDRA-18575:
-

Assignee: German Eichberger

> Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
> --
>
> Key: CASSANDRA-18575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18575
> Project: Cassandra
>  Issue Type: Bug
>Reporter: German Eichberger
>    Assignee: German Eichberger
>Priority: Normal
>
> Cassandra 3.0 has ciphers hard coded and thus not allow more recent and 
> secure ciphers for gossip connections complicating migrations to later 
> versions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols

[German Eichberger (Jira)]

German Eichberger created CASSANDRA-18575:
-

 Summary: Backport Cassandra-10508 Remove hard-coded SSL cipher 
suites and protocols
 Key: CASSANDRA-18575
 URL: https://issues.apache.org/jira/browse/CASSANDRA-18575
 Project: Cassandra
  Issue Type: Bug
Reporter: German Eichberger


Cassandra 3.0 has ciphers hard coded and thus not allow more recent and secure 
ciphers for gossip connections complicating migrations to later versions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[German Eichberger (Jira)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

German Eichberger updated CASSANDRA-10508:
--
Fix Version/s: 3.0.x

> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>  Labels: lhf
> Fix For: 3.0.x, 3.6
>
> Attachments: 10508-trunk.patch
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
> now require Java 8 which comes with solid defaults for these kind of SSL 
> settings and I'm wondering if the current behavior shouldn't be re-evaluated. 
> In my impression the way cipher suites are currently whitelisted is 
> problematic, as this will prevent the JVM from using more recent and more 
> secure suites that haven't been added to the hard-coded list. JVM updates may 
> also cause issues in case the limited number of ciphers cannot be used, e.g. 
> see CASSANDRA-6613.
> -Looking at the source I've also stumbled upon a bug in the 
> {{filterCipherSuites()}} method that would return the filtered list of 
> ciphers in undetermined order where the result is passed to 
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
> order of preference 
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you 
> may end up with weaker algorithms on the top. Currently it's not that 
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the 
> question if it still really makes sense to work with the cipher list at all 
> in the Cassandra code base.- (fixed in CASSANDRA-11164)
> Another way to effect used ciphers is by changing the security properties. 
> This is a more versatile way to work with cipher lists instead of relying on 
> hard-coded values, see 
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
>  for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted 
> anyway and will stop using safer protocol sets on new JVM releases or user 
> request. Again, we should stick with the JVM defaults. Using the 
> {{jdk.tls.client.protocols}} systems property will always allow to restrict 
> the set of protocols in case another emergency fix is needed. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [Virtio-fs] Is there a way to get NFS and/or NFSoRDMA to play nice with Virtio-FS?

[German Maglione]

On Sun, May 28, 2023 at 3:27 PM Ewen Chan  wrote:

> German:
>
> I finally got around to testing this and unfortunately, I am still getting
> the stale file handle error.
>
> Here is the command that I used for virtiofsd (which is embedded inside a
> startup script file in Proxmox).
>
> nohup /usr/lib/kvm/virtiofsd --syslog --daemonize
> --socket-path=/var/run/shared-fs.sock -o source=/export/myfs/ -o cache=none
> &> /dev/null  &
>
> If you have any other suggestions, that would be greatly appreciated.
>
>
Sadly no, since FUSE does not support persistent file handles, I don't
think it would work
(I know the NFsv4 protocol defines volatile file handles, but idk if that
is currently implemented or even if it would solve the problem)

Maybe you could try with a nfs proxy



> Thank you.
>
> Sincerely,
> Ewen
> --
> *From:* German Maglione 
> *Sent:* May 14, 2023 1:06 PM
> *To:* Ewen Chan 
> *Cc:* virtio-fs@redhat.com 
> *Subject:* Re: [Virtio-fs] Is there a way to get NFS and/or NFSoRDMA to
> play nice with Virtio-FS?
>
> Hi Ewen,
>
> On Sun, May 14, 2023 at 9:49 AM Ewen Chan  wrote:
>
> To Whom It May Concern:
>
> I'm using Proxmox 7.3-4 and I have a CentOS 7.7.1908 VM that's able to
> share data/files via Virtio-FS. That part is working fine.
>
> However, if I try to export that VirtIO-FS "target" as a NFS export,
> whenever my other computers connect to that NFS share, it will say that the
> folders have stale NFS handles.
>
> Is there a way to fix/resolve this?
>
> Here is the output for /etc/exports:
>
> /export *(rw,async,no_root_squash,no_all_squash,no_subtree_check,fsid=4)
>
> I have tried rebooting the clients multiple times, along with
> mounting/unmounting said NFS share and it doesn't appear to make any
> difference.
>
>
> Just to confirm, you want to share a folder using virtiofs with a VM, and
> then that VM running as an NFS server sharing that same folder over nfs, am
> I right?
>
> If that is the case, it's not possible (*) the NFS server requires
> persistent file handles that FUSE does not support.
>
> (*) I'm not sure, but IIRC Miklos said it could work if you disable the
> cache, so you can try running virtiofsd with `--cache=none` (let me know if
> that work).
>
>
>
>
> Your help is greatly appreciated.
>
> Thank you.
>
> Sincerely,
> Ewen
> ___
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs
>
>
>
> --
> German
>


-- 
German
___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

Re: Re: [VOTE] CEP-30 ANN Vector Search

[German Eichberger via dev]

+ 1

I am seeing ANN Vector Search pop up in every database...

From: Patrick McFadin 
Sent: Thursday, May 25, 2023 11:29 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] CEP-30 ANN Vector Search

+1
Love the buzz this creating with new users. Thanks for the work on this 
Jonathan.

On Thu, May 25, 2023 at 8:45 AM Jonathan Ellis 
mailto:jbel...@gmail.com>> wrote:
Let's make this official.

CEP: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes

POC that demonstrates all the big rocks, including distributed queries: 
https://github.com/datastax/cassandra/tree/cep-vsearch

--
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: [Virtio-fs] vm hangs when booting with virtiofs

[German Maglione]

I'm copying your response to this email

> >If you swap your win11 for a linux guest (using the same libvirt xml)
are you able to reproduce the error?
> do you think the guest type matters much?

Yes, because the windows guest uses a different driver. So the problem
could be virtiofsd daemon,
the linux kernel or the windows drivers


On Thu, May 25, 2023 at 8:38 AM daggs  wrote:

> Greetings German,
> >
> >Sent: Wednesday, May 24, 2023 at 5:51 PM
> >From: "German Maglione" 
> >To: "daggs" 
> >Cc: virtio-fs@redhat.com
> >Subject: Re: [Virtio-fs] vm hangs when booting with virtiofs
> >
> >
> >
> >>On Sat, May 20, 2023 at 12:15 PM daggs  da...@gmx.com]> wrote:Greetings,
> >>
> >>I'm trying to boot a win11 vm with a virtiofs fs and the system just
> hangs on boot, I'd like some incites on what is the issue.
> >>here is what I'm using:
> >>- kernel 6.3.3
> >>- libvirt 9.3.0
> >>- qemu 8.0.0
> >>- virtiofsd 1.5.1
> >>
> >>I'm using the following cmd to run virtiofsd using socket: virtiofsd
> --socket-path=/var/lib/libvirt/helpers_state/windows/linux_home.socket
> --shared-dir /home/daggs --cache auto
> >>where /var/lib/libvirt/helpers_state/windows/ is a tmpfs mount of 16K
> (tried with 1M too, same behavior)
> >>the virtiofsd invocation is issued inside the prepare and begin qemu
> hook on libvirt.
> >>I see this after virtiofsd is started: [2023-05-20T08:41:18Z INFO
> virtiofsd] Waiting for vhost-user socket connection...
> >>and I call it like this: nohup  &
> >>
> >>the vm's relevant config is this:
> >>
> >>...
> >>24582144
> >>24582144
> >>
> >>
> >>
> >>
> >>12
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>...
> >>
> >>
> >>
> >>
> >>
> >>...
> >>
> >>
> >>
> >> socket='/var/lib/libvirt/helpers_state/windows/linux_home.socket'/>
> >>
> >> function='0x0'/>
> >>
> >>...
> >>
> >>
> >>I'm running it via virsh, added -d 4, no errors in the log
> >>when it is stuck, I get a black screen (using gpu pt to guest which work
> without it), ps shows both virsh start cmd running and stuck, two virtiofsd
> instances are up.
> >>any ideas how to solve this?
> >>
> >>
> >I forgot, could you replace your '/usr/bin/virtiofsd' with a shell script
> that runs `virtiofsd --log-level=debug ...` and post the log output
> >
> >If you want, you can open an issue here:
> >
> https://gitlab.com/virtio-fs/virtiofsd/-/issues[https://gitlab.com/virtio-fs/virtiofsd/-/issues]
> do you mean run it from inside libvirt?
> I tried that, seems like virtiofsd fails because libvirt uses deprecated
> cli params
> that is why I'm using sockets and running it from outside libvirt
>
>
Oh great, I didn't realize you were calling virtiofsd directly, easier
then, just call
virtiofsd --log-level=debug

and please also using strace, like:
strace -f -o vfsd.strace.log  virtiofsd ...



> >>
> >>Thanks,
> >> Thanks,
> >>
> >>Dagg
> >>
> >>___
> >>Virtio-fs mailing list
> >>Virtio-fs@redhat.com[mailto:Virtio-fs@redhat.com]
> >>https://listman.redhat.com/mailman/listinfo/virtio-fs
> >
> >
> >--
> >
> >German
>
> Thanks,
>
> Dagg
>
>

-- 
German
___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

Re: [Virtio-fs] vm hangs when booting with virtiofs

[German Maglione]

On Sat, May 20, 2023 at 12:15 PM daggs  wrote:

> Greetings,
>
> I'm trying to boot a win11 vm with a virtiofs fs and the system just hangs
> on boot, I'd like some incites on what is the issue.
> here is what I'm using:
> - kernel 6.3.3
> - libvirt 9.3.0
> - qemu 8.0.0
> - virtiofsd 1.5.1
>
> I'm using the following cmd to run virtiofsd using socket: virtiofsd
> --socket-path=/var/lib/libvirt/helpers_state/windows/linux_home.socket
> --shared-dir /home/daggs --cache auto
> where /var/lib/libvirt/helpers_state/windows/ is a tmpfs mount of 16K
> (tried with 1M too, same behavior)
> the virtiofsd invocation is issued inside the prepare and begin qemu hook
> on libvirt.
> I see this after virtiofsd is started: [2023-05-20T08:41:18Z INFO
> virtiofsd] Waiting for vhost-user socket connection...
> and I call it like this: nohup  &
>
> the vm's relevant config is this:
> 
> ...
> 24582144
> 24582144
> 
> 
> 
> 
> 12
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> ...
> 
> 
> 
> 
> 
> ...
> 
> 
> 
> 
> 
> 
> 
> ...
> 
>
> I'm running it via virsh, added -d 4, no errors in the log
> when it is stuck, I get a black screen (using gpu pt to guest which work
> without it), ps shows both virsh start cmd running and stuck, two virtiofsd
> instances are up.
> any ideas how to solve this?
>
>
I forgot, could you replace your '/usr/bin/virtiofsd' with a shell script
that runs `virtiofsd --log-level=debug ...` and post the log output

If you want, you can open an issue here:
https://gitlab.com/virtio-fs/virtiofsd/-/issues

Thanks,


> Thanks,
>
> Dagg
>
> ___
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs
>
>

-- 
German
___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

Re: [Virtio-fs] vm hangs when booting with virtiofs

[German Maglione]

Hi,

On Sat, May 20, 2023 at 12:15 PM daggs  wrote:

> Greetings,
>
> I'm trying to boot a win11 vm with a virtiofs fs and the system just hangs
> on boot, I'd like some incites on what is the issue.
> here is what I'm using:
> - kernel 6.3.3
> - libvirt 9.3.0
> - qemu 8.0.0
> - virtiofsd 1.5.1
>

If you swap your win11 for a linux guest (using the same libvirt xml) are
you able to reproduce the error?


>
> I'm using the following cmd to run virtiofsd using socket: virtiofsd
> --socket-path=/var/lib/libvirt/helpers_state/windows/linux_home.socket
> --shared-dir /home/daggs --cache auto
> where /var/lib/libvirt/helpers_state/windows/ is a tmpfs mount of 16K
> (tried with 1M too, same behavior)
> the virtiofsd invocation is issued inside the prepare and begin qemu hook
> on libvirt.
> I see this after virtiofsd is started: [2023-05-20T08:41:18Z INFO
> virtiofsd] Waiting for vhost-user socket connection...
> and I call it like this: nohup  &
>
> the vm's relevant config is this:
> 
> ...
> 24582144
> 24582144
> 
> 
> 
> 
> 12
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> ...
> 
> 
> 
> 
> 
> ...
> 
> 
> 
> 
> 
> 
> 
> ...
> 
>
> I'm running it via virsh, added -d 4, no errors in the log
> when it is stuck, I get a black screen (using gpu pt to guest which work
> without it), ps shows both virsh start cmd running and stuck, two virtiofsd
> instances are up.
> any ideas how to solve this?
>
> Thanks,
>
> Dagg
>
> ___
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs
>
>

-- 
German
___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

Re: [Virtio-fs] Is there a way to get NFS and/or NFSoRDMA to play nice with Virtio-FS?

[German Maglione]

Hi Ewen,

On Sun, May 14, 2023 at 9:49 AM Ewen Chan  wrote:

> To Whom It May Concern:
>
> I'm using Proxmox 7.3-4 and I have a CentOS 7.7.1908 VM that's able to
> share data/files via Virtio-FS. That part is working fine.
>
> However, if I try to export that VirtIO-FS "target" as a NFS export,
> whenever my other computers connect to that NFS share, it will say that the
> folders have stale NFS handles.
>
> Is there a way to fix/resolve this?
>
> Here is the output for /etc/exports:
>
> /export *(rw,async,no_root_squash,no_all_squash,no_subtree_check,fsid=4)
>
> I have tried rebooting the clients multiple times, along with
> mounting/unmounting said NFS share and it doesn't appear to make any
> difference.
>
>
Just to confirm, you want to share a folder using virtiofs with a VM, and
then that VM running as an NFS server sharing that same folder over nfs, am
I right?

If that is the case, it's not possible (*) the NFS server requires
persistent file handles that FUSE does not support.

(*) I'm not sure, but IIRC Miklos said it could work if you disable the
cache, so you can try running virtiofsd with `--cache=none` (let me know if
that work).




> Your help is greatly appreciated.
>
> Thank you.
>
> Sincerely,
> Ewen
> ___
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs
>


-- 
German
___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs

[kwin] [Bug 469198] Cursor shadow glitch

[German P]

https://bugs.kde.org/show_bug.cgi?id=469198

--- Comment #1 from German P  ---
Created attachment 158570
  --> https://bugs.kde.org/attachment.cgi?id=158570=edit
cursor glitch

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 469198] New: Cursor shadow glitch

[German P]

https://bugs.kde.org/show_bug.cgi?id=469198

Bug ID: 469198
   Summary: Cursor shadow glitch
Classification: Plasma
   Product: kwin
   Version: 5.27.4
  Platform: Manjaro
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: wayland-generic
  Assignee: kwin-bugs-n...@kde.org
  Reporter: german...@hotmail.com
  Target Milestone: ---

When hovering the cursor close to a window border or title bar the cursor
shadow becomes thicker.
I attached a video showing the bug. This happens on wayland session.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Manjaro Kernel 6.3.0
KDE Plasma Version: 5.27.4 Wayland
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9 - 6.5.0

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

[German Eichberger via dev]

All,

What does it mean to be OpenSource? For me the community is 
developers/maintainers who work on Cassandra, operators who run Cassandra, and 
developers who write applications which use Cassandra. We all need to work 
together to make Cassandra successful - and we need to listen to each other to 
make the project successful.

It's apparent that a sizable number of people haven't migrated from 3.11 to 4.x 
- this might be because the EOL announcement has been confusing and what EOL 
means is fuzzy. Does the project still fix CVEs, will there be infrastructure 
if someone wants to fix something, etc.  So at a minimum I would expect 
documentation and agreement around those things.

If you look at Ubuntu and Java they distinguish between LTS releases and normal 
releases - but they are also doing this for a long time. The quicker release 
cycle (a new release every year) is sort of new-ish and hasn't been digested by 
all operators and users. So given 3.11 only extra support for a limited time to 
aid the transition like OpenJDK is doing for Java 8 might be prudent - Mick 
raises a valid point that if we go out and say "this is the new EOL, but this 
time we mean it" might encourage people to hope for another extension. I have 
no good answer other than communicate harder and more clearly - the status quo 
lacks clarity which is worse.

The other point Mick raises which releases to support gets to another 
discussion: As of today operators need to upgrade every two years and (also 
jump versions) aka I would need to go 3.11->4.1 right when it came out to get 
the full two year "support". I might feel uncomfortable going to a release 
which has just been released so realistically I need to update in between one 
and two years - give or take. This raises the question if we should dedicate 
some versions as LTS releases meaning they get longer support. Five years is 
common but that is also up for discussion. As an added benefit if there are 
commercial entities wanting to offer paid support they could focus on the LTS 
releases and bundle resources for the upstream support.

This is a good discussion and I feel especially the implied CVE support needs 
to be more formalized.

Thanks for indulging me,
German


From: Jacek Lewandowski 
Sent: Thursday, April 13, 2023 11:23 PM
To: dev@cassandra.apache.org 
Subject: Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

To me, as this is an open source project, we, the community, do not have to do 
anything, we can, but we are not obliged to, and we usually do that because we 
want to :-)

To me, EOL means that we move focus to newer releases. Not that we are 
forbidden to do anything in the older ones. One formal point though is the 
machinery - as long as we have the machinery to test and release, that's all we 
need. However, in face of coming changes in testing, I suppose some extra 
effort will have to be done to support older versions. Finding people who want 
to help out with that could be a kind of validation whether that effort is 
justified.

btw. We have recently agreed to keep support for M sstables format (3.0 - 3.11).

thanks,
- - -- --- -  -
Jacek Lewandowski


czw., 13 kwi 2023 o 21:59 Mick Semb Wever 
mailto:m...@apache.org>> napisał(a):
Yes, this would be great. Right now users are confused what EOL means and what 
they can expect.


I think the project would need to land on an agreed position.  I tried to find 
any reference to my earlier statement around CVEs on the latest unmaintained 
branch but could not find it (I'm sure it was mentioned somewhere :(

How many past branches?  All CVEs?  What if CVEs are in dependencies?
And is this a slippery slope, will such a formalised and documented commitment 
lead to more users on EOL versions? (see below)
How do other committers feel about this?


I am also asking specifically for 3.11 since this release has been around so 
long that it might warrant longer support than what we would offer for 4.0.


This logic can also be the other way around :-)

We should be sending a clear signal that OSS users are expected to perform a 
major upgrade every ~two years.  Vendors can, and are welcome to solve this, 
but the project itself does not support any user's production system, it only 
maintains code branches and performs releases off them, with our focus on 
quality solely on those maintained branches.

[jira] [Commented] (CASSANDRA-18120) Single slow node dramatically reduces cluster write throughput regardless of CL

[German Eichberger (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712089#comment-17712089
 ] 

German Eichberger commented on CASSANDRA-18120:
---

This is very interesting and I am by far no Cassandra expert but this sounds 
like dynamic snitching (see 
[https://cassandra.apache.org/doc/latest/cassandra/architecture/snitch.html)] 
for writes  instead of reads. So I would guess from a design it should like it 
for writes. I am also curious why only batch writes are affected and not all 
writes?

 

 

> Single slow node dramatically reduces cluster write throughput regardless of 
> CL
> ---
>
> Key: CASSANDRA-18120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18120
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Dan Sarisky
>Assignee: Maxim Chanturiay
>Priority: Normal
>
> We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, 
> QUORUM, or LOCAL_QUORUM)
>  
> On clusters of any size - a single extremely slow node causes a ~90% loss of 
> cluster-wide throughput using batched writes.  We can replicate this in the 
> lab via CPU or disk throttling.  I observe this in 3.11, 4.0, and 4.1.
>  
> It appears the mechanism in play is:
> Those logged batches are immediately written to two replica nodes and the 
> actual mutations aren't processed until those two nodes acknowledge the batch 
> statements.  Those replica nodes are selected randomly from all nodes in the 
> local data center currently up in gossip.  If a single node is slow, but 
> still thought to be up in gossip, this eventually causes every other node to 
> have all of its MutationStages to be waiting while the slow replica accepts 
> batch writes.
>  
> The code in play appears to be:
> See
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245].
>   In the method filterBatchlogEndpoints() there is a
> Collections.shuffle() to order the endpoints and a
> FailureDetector.isEndpointAlive() to test if the endpoint is acceptable.
>  
> This behavior causes Cassandra to move from a multi-node fault tolerant 
> system toa collection of single points of failure.
>  
> We try to take administrator actions to kill off the extremely slow nodes, 
> but it would be great to have some notion of "what node is a bad choice" when 
> writing log batches to replica nodes.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

[German Eichberger via dev]

Josh,





We already have an understanding and precedence in place that CVEs on
the previous unmaintained branch are addressed and released.
Correct me if I'm wrong German, but the question I got from your email was 
effectively "If we  consider formalizing our commitment to fixing CVE's on 
older branches that are out of formal bugfix support as a community, what are 
the benefits and costs to doing that"?

Yes, this would be great. Right now users are confused what EOL means and what 
they can expect.

I am also asking specifically for 3.11 since this release has been around so 
long that it might warrant longer support than what we would offer for 4.0.

On Thu, Apr 13, 2023, at 2:47 PM, Mick Semb Wever wrote:
>
> There have been several discussions on slack [1], [2] to support 3.11 beyond 
> the date stated on the web [3] which is May-July 23 and given it's April 
> that's an unlikely date.
>


Strictly speaking it is maintained until the 5.0 GA release. We should
update the downloads page accordingly.


>
> So we will support anyway but I would like to start a broader discussion if 
> we, the community, are interested in at a minimum CVE only support, maybe bug 
> fixes as well,  after 5.0 is released for 3.11 and if so for how long - 
> something like a Cassandra LTS policy.
>



The community's resources are limited, and the statement is intended
to avoid tying up resources and to avoid letting users down. This is
open source and "to upgrade" is often our easy and pragmatic answer.

It is not a statement that fixes to older branches will be rejected. A
(two) committers can still push to older branches, and a release can
still happen if you find someone to do it (and three PMCs to +1 it).
This is why the 2.2 branch is still present on ci-cassandra.a.o. If
vendors want to provide support for versions longer and can make the
commitment to upstream those efforts (whether that's bug-fixes and
releases, or only bug-fixes) the machinery is in place to accept it.

We already have an understanding and precedence in place that CVEs on
the previous unmaintained branch are addressed and released.

Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

[German Eichberger via dev]

+1

(Recently learned anyone can vote so using my new discovered powers)

From: Josh McKenzie 
Sent: Thursday, April 13, 2023 6:59 AM
To: dev 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

+1

On Thu, Apr 13, 2023, at 3:17 AM, Benjamin Lerer wrote:
+1

Le jeu. 13 avr. 2023 à 08:56, Tommy Stendahl via dev 
mailto:dev@cassandra.apache.org>> a écrit :
+1 (nb)

-Original Message-
From: Brandon Williams 
mailto:brandon%20williams%20%3cdri...@gmail.com%3e>>
Reply-To: dev@cassandra.apache.org
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT
Date: Tue, 11 Apr 2023 05:30:59 -0500


+1



On Tue, Apr 11, 2023 at 2:54 AM Miklosovic, Stefan

<

stefan.mikloso...@netapp.com

> wrote:


Lets just vote on that straight away. Nothing significant has changed except 
zstd-jni update to 1.5.5. If all goes well it would be nice to have the vote 
resolved by this Friday's noon UTC.


Proposing the test build of Cassandra 4.0.9 for release.


sha1: e9f8f2efa2ba75f223f31ca6801aff3fe2964745

Git:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.9-tentative


Maven Artifacts:

https://repository.apache.org/content/repositories/orgapachecassandra-1286/org/apache/cassandra/cassandra-all/4.0.9/



The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here:

https://dist.apache.org/repos/dist/dev/cassandra/4.0.9/



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]: CHANGES.txt:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.9-tentative


[2]: NEWS.txt:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.9-tentative

(CVE only) support for 3,11 beyond published EOL

[German Eichberger via dev]

All,

There have been several discussions on slack [1], [2] to support 3.11 beyond 
the date stated on the web [3] which is May-July 23 and given it's April that's 
an unlikely date.

Given that there are still a sizable number of users on 3.11 in [2] we talked 
about a CVE only support for some time. When we discussed that internally at 
Azure we entertained supporting until Java 8 is EOL but with that now being 
12/31/2030 [4] we quickly gave up on that and are now thinking a shorter time. 
So we will support anyway but I would like to start a broader discussion if we, 
the community, are interested in at a minimum CVE only support, maybe bug fixes 
as well,  after 5.0 is released for 3.11 and if so for how long - something 
like a Cassandra LTS policy.

Thanks,
German




[1] https://the-asf.slack.com/archives/CJZLTM05A/p1678451091766109
[2] https://the-asf.slack.com/archives/CK23JSY2K/p1680125394038599
[3] https://cassandra.apache.org/_/download.html
[4] https://endoflife.date/java