On Fri, Jul 7, 2023 at 2:20 PM Miklosovic, Stefan
wrote:
>
> Great thanks. That might work.
>
> So we do not change the default output unless there is json / yaml equivalent.
>
> Once there is, we are free to change the default output however we want.
Yes, exactly. Then we have the best of both
Hi Yuki, Jeremiah & Christopher,
Thank you very much for the feedback.
Regarding removing superuser check for adding/removing identities, I have
relaxed that check and added permissions check instead. With this change
only users with appropriate permissions to add/drop identities can perform
that
Great thanks. That might work.
So we do not change the default output unless there is json / yaml equivalent.
Once there is, we are free to change the default output however we want.
From: Brandon Williams
Sent: Friday, July 7, 2023 21:17
To: dev@cassand
On Fri, Jul 7, 2023 at 2:11 PM Miklosovic, Stefan
wrote:
>
> Yes, that is true, but the original, unfixed, output, is still there. Are we
> OK with that?
When we have a serialized output available, we do whatever we like to
the display output.
Yes, that is true, but the original, unfixed, output, is still there. Are we OK
with that?
Now the command "nodetool command" writes this:
someValue: 1
Another Value: 2
The Third Value: 3
You say that, lets add a flag to this too, -j (as in json), so a user will get:
{
"some_value": 1,
On Fri, Jul 7, 2023 at 2:02 PM Miklosovic, Stefan
wrote:
>
> There is just no clear path how to improve that over time and exposing the
> same output via different format is not really solving it ... the
> discrepancies are still there.
I'm not sure what you mean, can you explain? In my mind,
Thank you Brandon for further clarification of your position on this.
While I get the necessity of being compatible is real, I just find the fact
that we need to do this across majors to be just too much. Are we all aware
that if we can not change it, this is just a snowball getting bigger over
On Fri, Jul 7, 2023 at 10:21 AM Miklosovic, Stefan
wrote:
>
> Anyway, the main question here is if we are OK to change the output in majors.
I think we always want to strive for compatibility whenever possible.
My personal litmus test is "can this information be obtained
elsewhere?" and if the an
This really is great work Maxim; definitely appreciate all the hard work that's
gone into it and I think the users will too.
In terms of where it should land, we discussed this type of question at length
on the ML awhile ago and ended up codifying it in the wiki:
https://cwiki.apache.org/conflu
I think 500 runs combining all configs could be reasonable, since it's
unlikely to have config-specific flaky tests. As in five configs with 100
repetitions each.
On Fri, 7 Jul 2023 at 16:14, Josh McKenzie wrote:
> Maybe. Kind of depends on how long we write our tests to run doesn't it? :)
>
> B
On Fri, Jul 7, 2023 at 10:21 AM Miklosovic, Stefan
wrote:
> If that is the case, we should start to treat this problem completely
> differently and we should not rely on the output of tooling at all and we
> should either provide corresponding JMX method to retrieve it or we should
> offer othe
Hi list,
I want to clarify the policy we have when we want to / going to change the
output of the tooling (nodetool or tools/bin etc.).
I am not sure it is written somewhere explicitly, but how I get it from the
gossip over years is that we should not change the output (e.g. changing the
name
Maybe. Kind of depends on how long we write our tests to run doesn't it? :)
But point taken. Any non-trivial test would start to be something of a beast
under this approach.
On Fri, Jul 7, 2023, at 11:12 AM, Brandon Williams wrote:
> On Fri, Jul 7, 2023 at 10:09 AM Josh McKenzie wrote:
> > 3. M
On Fri, Jul 7, 2023 at 10:09 AM Josh McKenzie wrote:
> 3. Multiplexed tests (changed, added) run against all JDK's and a broader
> range of configs (no-vnode, vnode default, compression, etc)
I think this is going to be too heavy...we're taking 500 iterations
and multiplying that by like 4 or 5?
> I wouldn’t also advocate not running JDK17 tests until we enable all test
> suites post-commit
What about this:
1. Pre-commit suite runs against just 1 JDK (latest supported / most common /
default)
2. Pre-commit suite runs against default config
3. *Multiplexed tests* (changed, added) run agai
15 matches
Mail list logo
