+1 binding
Thanks,
Haiting
On Wed, Jun 28, 2023 at 10:17 AM houxiaoyu wrote:
>
> +1 (non-binding)
>
> Xiaoyu Hou
>
> steven lu 于2023年6月28日周三 09:40写道：
>
> > Hi, community:
> >
> > # Motivation
> >
> > reformat property,for a http header name cannot contain the following
> > prohibited characters
+1 (binding)
Thanks,
Yunze
On Tue, Jun 27, 2023 at 7:53 AM PengHui Li wrote:
>
> +1 (binding)
>
> Regards,
> Penghui
>
> On Mon, Jun 26, 2023 at 12:19 PM Yunze Xu wrote:
>
> > I have left some comments in the proposal so please hold this vote
> > until the comments are addressed.
> >
> > Thanks
>> Pulsar SQL
>> objections
>It's not objections the blocker, but volunteers.
IIRC, there were objections to moving pulsar sql to its own repo
because there was an effort to contribute it to trino. Given that the
trino contribution has stalled, I think we should move pulsar sql out
of the apache/p
> I think it's better to disable (or quarantine) a test if it blocks master and
> there's no immediate solution.
It is regrettable to disable a test, but given that this test is
passing locally, I agree with quarantining the test.
Thanks,
Michael
On Wed, Jun 28, 2023 at 12:10 AM Lari Hotari wr
I think it's better to disable (or quarantine) a test if it blocks master and
there's no immediate solution.
-Lari
On 2023/06/28 01:52:14 tison wrote:
> See also https://github.com/apache/pulsar/issues/20661
>
> Enrico and I both verified that it works well locally, so that can be an
> env issu
> Why not disable auto-creation for system topics? and then we can create it
> before the broker start. which can avoid introduce complex meaning of
> `allowAutoTopicCreationType` configuration.
A broker cannot know all of the system topics to create at startup.
For example, some system topics a
Hi all,
I would like to propose releasing the Pulsar Node.js client v1.9.0
It has been over 2 months since the last release (1.8.2). There have
been many new features and bug fixes since then. It's time to release
a new version.
- https://github.com/apache/pulsar-client-node/milestone/14?clo
+1 (non-binding)
Xiaoyu Hou
steven lu 于2023年6月28日周三 09:40写道：
> Hi, community:
>
> # Motivation
>
> reformat property,for a http header name cannot contain the following
> prohibited characters: =,;: \t\r\n\v\f
>
> for example:
> {"city=shanghai":"tag"}
> when we run `bin/pulsar-admin topics get
Hi, Michael
I've got several questions and hope you can help answer.
Why not disable auto-creation for system topics? and then we can create it
before the broker start. which can avoid introduce complex meaning of
`allowAutoTopicCreationType` configuration.
Plus, why we chose the non-partition
the DISCUSS is passed,I have send the VOTE for this PIP
https://lists.apache.org/thread/g354684m9h495o3p0kmzb7fh7vfxhddx
On 2023/06/21 03:22:52 steven lu wrote:
> # Motivation
>
> reformat property,for a http header name cannot contain the following
> prohibited characters: =,;: \t\r\n\v\f
>
>
See also https://github.com/apache/pulsar/issues/20661
Enrico and I both verified that it works well locally, so that can be an
env issue or unstable dependency - I checked the ES image not changed,
though.
If we cannot locate the cause quickly, perhaps disable the test to unblock
other PRs first
Hi, community:
# Motivation
reformat property,for a http header name cannot contain the following
prohibited characters: =,;: \t\r\n\v\f
for example:
{"city=shanghai":"tag"}
when we run `bin/pulsar-admin topics get-message-by-id `, it will
throw exception, the exception is:
`Reason: java.util.co
Hi Pulsar Community,
After several recent issues regarding incorrectly auto created topics,
I think we should default to creating system topics as non-partitioned
topics when auto created.
Lari put together a PR here
https://github.com/apache/pulsar/pull/20397. The PR has relevant
context.
Let m
I agree that the terminology is confusing. On a practical note, that
confusion likely caused this bug [0].
> I'd like to say "a partitioned topic is a topic that consists of
> multiple non-partitioned topics". It's better not to use the "internal
> topic" concept.
+1
In general, I think the equi
I removed the "release/2.9.6" label from 50 PRs:
https://github.com/apache/pulsar/pull/20533
https://github.com/apache/pulsar/pull/20513
https://github.com/apache/pulsar/pull/20482
https://github.com/apache/pulsar/pull/20416
https://github.com/apache/pulsar/pull/20363
https://github.com/apache/pul
In light of this thread, I think we have a (lazy) consensus that 2.8
and 2.9 are EOL and we will continue to maintain 2.10.
Would someone be able to update the website to say that 2.10 is not EOL?
I will update the GitHub labels to indicate the 2.9 label should no
longer be used.
Thanks,
Michael
While, I visit tests/integration recently that it can be clear how to
factor out the testcontainers-based integration utils. Let me file an issue
to track the work so that we have more visibility about the progress and
hopefully a nudge to the target - of course separating those code is a good
idea
> Pulsar SQL
> objections
It's not objections the blocker, but volunteers.
A comparable example is that Flink firstly tried to move out connectors in
2018 and finally made it happen in 2022 (specifically, Kafka connector
_today_[1]). That indicates such initiatives require heavy development.
For
I hope we could finally resume the work on PIP-62 and continue with
the plan that was set in April 2020.
You can find old discussion threads about PIP-62 with this query:
https://lists.apache.org/list?dev@pulsar.apache.org:lte=10y:PIP-62
There was a discussion in July 2022 about moving Pulsar SQL
Il giorno mar 27 giu 2023 alle ore 12:58 Lari Hotari
ha scritto:
>
> I take my words back about branch-2.9 . It's also using Java 11 at runtime,
> so it should be possible to apply https://github.com/apache/pulsar/pull/20659
> to branch-2.9 too so that we get cgroup v2 support for Pulsar 2.9.x.
I take my words back about branch-2.9 . It's also using Java 11 at runtime, so
it should be possible to apply https://github.com/apache/pulsar/pull/20659 to
branch-2.9 too so that we get cgroup v2 support for Pulsar 2.9.x.
-Lari
On 2023/06/27 10:52:02 Lari Hotari wrote:
> We don't have any rele
We don't have any released stable version of Pulsar with cgroup v2 support.
Azure AKS Kubernetes 1.25+ switches to use cgroup v2 [1] and AKS Kubernetes
1.24 goes End-of-life on July 30, 2023 [2]. This is why this is becoming urgent.
GKE will continue to have a way to select between cgroup v1 & c
Yes we can.
It was a tentative goal of creating a new workflow to build releases,
especially for the pulsar-all docker image, that depends both on
pulsar main repo code and on Pulsar SQL,
that we wanted to remove from the base repository.
Enrico
Il giorno mar 27 giu 2023 alle ore 08:27 Asaf Mesi
Thanks. addressed in the PIP
Regards
Jiwei Guo (Tboy)
On Sun, Jun 25, 2023 at 6:05 PM PengHui Li wrote:
> Hi Jiwei,
>
> Do you need to change the REST API? or will it just apply to the Admin CLI?
> If it requires REST API changes, you should also reflect them in the
> proposal.
>
> And yes, u
24 matches
Mail list logo
