[GitHub] [pulsar-helm-chart] eolivelli merged pull request #193: [CI] Add job 45min timeout and cancel duplicate jobs

[GitBox]

eolivelli merged pull request #193:
URL: https://github.com/apache/pulsar-helm-chart/pull/193


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on pull request #192: [CI] Upgrade k8s to 1.18 and also upgrade helm, kind & chart releaser versions

[GitBox]

lhotari commented on pull request #192:
URL: 
https://github.com/apache/pulsar-helm-chart/pull/192#issuecomment-1003979521


   > Build failed:
   > 
   > : INSTALLATION FAILED: unable to build kubernetes objects from release 
manifest: unable to recognize "": no matches for kind "DaemonSet" in version 
"extensions/v1beta1
   
   @eolivelli  This problem is fixed now. PTAL


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] eolivelli commented on pull request #180: Use NIOServerCnxnFactory for Zookeeper to fix NPE issues with Pulsar 2.8.0+

[GitBox]

eolivelli commented on pull request #180:
URL: 
https://github.com/apache/pulsar-helm-chart/pull/180#issuecomment-1004013791


   I am following up with the issue on Zookeeper and I will help in cutting a 
release as soon as possible.
   It would be probably 3.7.1


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] eolivelli merged pull request #180: Use NIOServerCnxnFactory for Zookeeper to fix NPE issues with Pulsar 2.8.0+

[GitBox]

eolivelli merged pull request #180:
URL: https://github.com/apache/pulsar-helm-chart/pull/180


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on pull request #190: Bump to Pulsar 2.8.2

[GitBox]

lhotari commented on pull request #190:
URL: 
https://github.com/apache/pulsar-helm-chart/pull/190#issuecomment-1004035982


   It seems that #188 should also be resolved before switching to Pulsar 2.8.x .


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on pull request #190: Bump to Pulsar 2.8.2

[GitBox]

lhotari commented on pull request #190:
URL: 
https://github.com/apache/pulsar-helm-chart/pull/190#issuecomment-1004101125


   Failures in CI which points to #188. I'll push a fix to this PR.
   ```
   Unrecognized VM option 'PrintGCTimeStamps'
   Error: Could not create the Java Virtual Machine. 
   Error: A fatal exception has occurred. Program will exit. 
   Unrecognized VM option 'PrintGCTimeStamps'
   Error: Could not create the Java Virtual Machine. 
   Error: A fatal exception has occurred. Program will exit. 
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on issue #188: Unrecognized VM option 'PrintGCTimeStamps' - Unsupported Java 11 GC Flags causing init container fail

[GitBox]

lhotari commented on issue #188:
URL: 
https://github.com/apache/pulsar-helm-chart/issues/188#issuecomment-1004129237


   @samuelzimmermanphillips Thanks for reporting. This will be fixed as part of 
#190.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

upcoming change: Apache Pulsar Helm Chart switching from Pulsar 2.7.4 version to 2.8.2; known issue with ZK when TLS is enabled

[Lari Hotari]

Hi all,

There's an upcoming change in the Apache Pulsar Helm chart to finally
switch to Pulsar 2.8.x, more specifically to Apache Pulsar version 2.8.2 .
The latest Apache Pulsar Helm Chart release uses the Apache Pulsar 2.7.4
image.

The pull request to switch to Apache Pulsar image version 2.8.2 is current
in review:
https://github.com/apache/pulsar-helm-chart/pull/190

There's a known issue that Zookeeper TLS isn't stable because of
https://issues.apache.org/jira/browse/ZOOKEEPER-3988 (also reported in
apache/pulsar as https://github.com/apache/pulsar/issues/11070) .
The fix https://github.com/apache/zookeeper/pull/1770 is planned for
Zookeeper 3.7.1 version.
There's a workaround in the Apache Pulsar Helm chart when TLS isn't enabled
for Zookeeper. That was added by
https://github.com/apache/pulsar-helm-chart/pull/180 .
However, the workaround cannot be applied when TLS is enabled for Zookeeper.

Should we postpone switching to Apache Pulsar 2.8.2 in the Helm chart until
there's a fix for ZOOKEEPER-3988 /
https://github.com/apache/pulsar/issues/11070 ?

BR,
Lari

Re: [VOTE] Apache Pulsar 2.8.2 candidate 2

[Dave Fisher]

Hi Lin Lin -

We really need to complete this release and announce it ASAP.

Regards,
Dave

> On Dec 30, 2021, at 5:58 AM, Enrico Olivelli  wrote:
> 
> What's the status of this VOTE?
> 
> Enrico
> 
> Il Mer 22 Dic 2021, 10:34 Nicolò Boschi  ha scritto:
> 
>> +1 (non binding)
>> 
>> Checks:
>> - Checksum and signatures
>> - Apache Rat check passes
>> - Compile from source w JDK8
>> - Build docker image from source
>> - Run Pulsar standalone and produce-consume from CLI
>> - Verified Log4J inside lib/
>> 
>> -rw-r--r-- 1 root root   208235 Jan 22  2020
>> org.apache.logging.log4j-log4j-1.2-api-2.17.0.jar
>> 
>> -rw-r--r-- 1 root root   301776 Jan 22  2020
>> org.apache.logging.log4j-log4j-api-2.17.0.jar
>> 
>> -rw-r--r-- 1 root root  1789339 Jan 22  2020
>> org.apache.logging.log4j-log4j-core-2.17.0.jar
>> 
>> -rw-r--r-- 1 root root24252 Jan 22  2020
>> org.apache.logging.log4j-log4j-slf4j-impl-2.17.0.jar
>> 
>> -rw-r--r-- 1 root root35920 Jan 22  2020
>> org.apache.logging.log4j-log4j-web-2.17.0.jar
>> 
>> Il giorno mer 22 dic 2021 alle ore 06:37 Lin Lin  ha
>> scritto:
>> 
>>> 
>>> 
>>> On 2021/12/21 10:48:41 Shivji Kumar Jha wrote:
 Hi LinLin,
 
 Log4j version 2.16.0 has DDoS possibilities in some cases [1] . Can we
>>> move
 to Log4j 2.17.0 in 2.8.2?
 
 Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did
>>> not
> protect from uncontrolled recursion from self-referential lookups.
>> This
> allows an attacker with control over Thread Context Map data to
>> cause a
> denial of service when a crafted string is interpreted. This issue
>> was
> fixed in Log4j 2.17.0 and 2.12.3.
>>> 
>>> 
>>> Already included
>>> 
>> 
>> 
>> --
>> Nicolò Boschi
>> 

Sending 2.6 release line to EOF

[Enrico Olivelli]

Hello,
We are no more cutting releases out of branch-2.6

We must declare 2.6 EOF.

IIUC there is no process established for this at the moment in the Pulsar
project.

So for this time I will call out a VOTE next week, as we did not cut
releases for a few important bugs.

Thoughts?

Enrico

[GitHub] [pulsar-helm-chart] lhotari merged pull request #182: Fixes #177 Fix indentation of component, as it should be under the la…

[GitBox]

lhotari merged pull request #182:
URL: https://github.com/apache/pulsar-helm-chart/pull/182


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari closed issue #177: The indentation of dashboard-ingress.yaml is wrong, when deploying shows component not found.

[GitBox]

lhotari closed issue #177:
URL: https://github.com/apache/pulsar-helm-chart/issues/177


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] michaeljmarshall commented on a change in pull request #192: [CI] Upgrade k8s to 1.18 and also upgrade helm, kind & chart releaser versions

[GitBox]

michaeljmarshall commented on a change in pull request #192:
URL: https://github.com/apache/pulsar-helm-chart/pull/192#discussion_r777659034



##
File path: .gitignore
##
@@ -16,3 +16,6 @@ charts/**/*.lock
 
 PRIVATEKEY
 PUBLICKEY
+.vagrant/
+pulsarctl-amd64-linux.tar.gz
+pulsarctl-amd64-linux/

Review comment:
   I looked at my clone of the project, and I can see that I have 
`pulsarctl-amd64-darwin/` and `pulsarctl-amd64-darwin.tar.gz`. These names must 
be arch dependent.
   
   Why do we need these files/directories though? From what I can tell, it is 
because the tests use it to generate tokens/keys. It seems like we could use a 
more standard tool, like `openssl`, for token generation and then drop this 
dependency.
   
   If we want to worry about the dependency in another PR/thread, I think you 
could update this to `pulsarctl-**` for now.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: OWASP dependencies check on active branches

[Michael Marshall]

+1 - This is a great addition, thanks Nicolò.

I updated our Release Process wiki page so that Release Managers will
know to add new release branches to this GitHub workflow [0].

- Michael

[0] 
https://github.com/apache/pulsar/wiki/Release-process#1-create-the-release-branch

On Wed, Dec 22, 2021 at 10:08 AM Lari Hotari  wrote:
>
> Good work Nicolò! It's great to have OWASP dependency check handled for all
> active branches.
>
> -Lari
>
> On Wed, Dec 22, 2021 at 5:05 PM Nicolò Boschi  wrote:
>
> > Hello everyone,
> >
> > I created a couple of pull requests in order to run a periodic check on
> > Pulsar active branches. In this way we can proactively update dependencies
> > whenever is needed (for fixing CVE's purpose)
> >
> > The first one [0] is to make the check pass on branch-2.8
> > The second one [1] is to make the check pass on master and branch-2.9
> > The third one [2] is to make the periodic job running against master,
> > branch-2.8 and branch-2.9.
> >
> > We also have to port this PR [3] to branch-2.9
> >
> > I left out 2.7 branch because I have the impression (please confirm it) we
> > are no longer cherry-picking dependency upgrades. Also the check doesn't
> > exist at all in that branch.
> >
> > Let me know what you think.
> >
> > Thanks,
> > Nicolò Boschi
> >
> > [0] https://github.com/apache/pulsar/pull/13455
> > [1] https://github.com/apache/pulsar/pull/13451
> > [2] https://github.com/apache/pulsar/pull/13366
> > [3] https://github.com/apache/pulsar/pull/13364
> >

[GitHub] [pulsar-helm-chart] eolivelli commented on pull request #190: Bump to Pulsar 2.8.2

[GitBox]

eolivelli commented on pull request #190:
URL: 
https://github.com/apache/pulsar-helm-chart/pull/190#issuecomment-1004370311


   Also, why should we ship 2.8 as default instead of 2.9.1?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] michaeljmarshall commented on a change in pull request #183: Update ingress api version, extension/v1beta1 will not be supported i…

[GitBox]

michaeljmarshall commented on a change in pull request #183:
URL: https://github.com/apache/pulsar-helm-chart/pull/183#discussion_r25211



##
File path: charts/pulsar/templates/dashboard-ingress.yaml
##
@@ -19,7 +19,11 @@
 
 {{- if .Values.extra.dashboard }}
 {{- if .Values.dashboard.ingress.enabled }}
+{{- if semverCompare "<1.19-0" .Capabilities.KubeVersion.GitVersion }}

Review comment:
   @wangshu3000 - do you have a reference that documents `GitVersion`? I 
don't see that in the helm documentation 
(https://helm.sh/docs/chart_template_guide/builtin_objects/).
   
   I think we should prefer the logic described in this stack overflow answer: 
https://stackoverflow.com/a/66191437. Essentially, we can inspect the 
`APIVersion` to see if the api has `networking.k8s.io/v1` and branch 
accordingly.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] michaeljmarshall commented on pull request #183: Update ingress api version, extension/v1beta1 will not be supported i…

[GitBox]

michaeljmarshall commented on pull request #183:
URL: 
https://github.com/apache/pulsar-helm-chart/pull/183#issuecomment-1004388405


   @lhotari - do you know why the CI checks wouldn't have run for this PR? I 
haven't seen that happen before.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Sending 2.6 release line to EOF

[Dave Fisher]

I don’t think we need a VOTE. Let’s do this by LAZY CONSENSUS.

> On Jan 3, 2022, at 10:05 AM, Enrico Olivelli  wrote:
> 
> Hello,
> We are no more cutting releases out of branch-2.6
> 
> We must declare 2.6 EOF.
> 
> IIUC there is no process established for this at the moment in the Pulsar
> project.
> 
> So for this time I will call out a VOTE next week, as we did not cut
> releases for a few important bugs.
> 
> Thoughts?
> 
> Enrico

Re: Sending 2.6 release line to EOF

[陳智弘]

I think having a vote and quickly announce the EOF of 2.6.x will be better
to the community.


Dave Fisher  於 2022年1月4日 週二 06:06 寫道：

> I don’t think we need a VOTE. Let’s do this by LAZY CONSENSUS.
>
> > On Jan 3, 2022, at 10:05 AM, Enrico Olivelli 
> wrote:
> >
> > Hello,
> > We are no more cutting releases out of branch-2.6
> >
> > We must declare 2.6 EOF.
> >
> > IIUC there is no process established for this at the moment in the Pulsar
> > project.
> >
> > So for this time I will call out a VOTE next week, as we did not cut
> > releases for a few important bugs.
> >
> > Thoughts?
> >
> > Enrico
>
>

Re: Warm Geetings on New Year 2022

[Sijie Guo]

Thanks Yu and many contributors for the hard work on documentation!

Happy New Year!

- Sijie

On Fri, Dec 31, 2021 at 3:07 AM Yu  wrote:

> Hi Pulsar enthusiasts,
>
>
> With 2022 knocking on our doors, I would like to take this opportunity to
> express sincere gratitude to you for making what Pulsar is today and
> shaping what Pulsar will be tomorrow!
>
>
> This year, Pulsar is continued to be sought out by organizations
> developing messaging and event-streaming applications — from Fortune 100
> companies to forward-thinking start-ups — the community is growing quickly.
> This community growth has contributed to several milestones, including
> major releases, first-ever Pulsar Summits, 400+ contributors, and more.
> Regarding contributions, more people have shifted to contribute more
> documentation, that is awesome!
>
>
> As we know, documentation is the entry point into Pulsar for most people,
> and a lack of good documentation inherently limits its reach. Next year, we
> will continue to help users succeed with Pulsar, empower users to be
> self-sufficient, and encourage them to give further feedback with quality
> documentation. Until now, We have various PIPs [1] and documentation issues
> [2] to be finished on our plates. If you’re interested in getting involved
> with Pulsar, feel free to join us!
>
>
> Looking forward to another fruitful year ahead for Pulsar. Wishing you a
> New Year loaded with laughter and blessed with smiles. Wishing you a New
> Year that you remember all your life. Happy 2022!
>
>
> Cheers,
>
> Yu
>
>
> [1]
> https://docs.google.com/spreadsheets/d/1U2aYjla-oGxAHkCpdBCBy_EWNwHKOvAJ-6-3IiVrJ1U/edit#gid=1283297735
>
> [2]
> https://github.com/apache/pulsar/issues?q=is%3Aopen+is%3Aissue+label%3Adoc-required
>
>
>
> [image: image.png]
>
>

Re: Sending 2.6 release line to EOF

[Sijie Guo]

Agree to have a vote to keep a record.

- Sijie

On Mon, Jan 3, 2022 at 3:40 PM 陳智弘  wrote:

> I think having a vote and quickly announce the EOF of 2.6.x will be better
> to the community.
>
>
> Dave Fisher  於 2022年1月4日 週二 06:06 寫道：
>
> > I don’t think we need a VOTE. Let’s do this by LAZY CONSENSUS.
> >
> > > On Jan 3, 2022, at 10:05 AM, Enrico Olivelli 
> > wrote:
> > >
> > > Hello,
> > > We are no more cutting releases out of branch-2.6
> > >
> > > We must declare 2.6 EOF.
> > >
> > > IIUC there is no process established for this at the moment in the
> Pulsar
> > > project.
> > >
> > > So for this time I will call out a VOTE next week, as we did not cut
> > > releases for a few important bugs.
> > >
> > > Thoughts?
> > >
> > > Enrico
> >
> >
>

Re: Docker image docker pull apachepulsar/pulsar:2.8.2 missing from dockerhub

[Sijie Guo]

Hi Francisc,

The 2.8.2 image is there:
https://hub.docker.com/layers/apachepulsar/pulsar/2.8.2/images/sha256-d538416d5afe03360e10d5beb44bdad33d7303d137fc66c264108426875f61c6?context=explore

- Sijie

On Thu, Dec 30, 2021 at 8:15 AM Francisc Florian Munteanu <
francisc.florian.munte...@infovista.com> wrote:

> Hello all,
> we are in the process of updating our apachepulsar docker image
> dependency, due to the log4j2 vulnerabilities.
>
> We noticed that pulsar 2.8.2 was already released with the security fix:
> Upgrade to Log4J 2.17.0 to mitigate CVE-2021-45105 #13392<
> https://github.com/apache/pulsar/pull/13392>
>
> However we are not able to find the docker image in dockerhub.
>
> Do you have any expected date for apachepulsar/pulsar:2.8.2 (or higher
> version containing those fixes) to be released ?
>
> Thanks & Regards
> Francisc Munteanu
>

Re: [DISCUSS] Apache Pulsar 2.10.0 release

[Sijie Guo]

+1.

All make sense to me!

We probably need to move to the feature frozen stage in order to cut a
release at the end of January.

- Sijie

On Sun, Dec 26, 2021 at 8:46 PM PengHui Li  wrote:

> Hi, everyone
>
> I hope you’ve all been doing well. I would like to start an email thread to
> discuss features that we planned for 2.10.0.
> According to the time-based release plan
> https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan,
> we should release 2.10.0 at the end of December 2021, since we have reached
> the end of December,
> I would like to target the 2.10.0 to the end of January 2022
>
> There are some powerful features and enhancements in 2.10.0 such as
>
> - PIP 84: Message redelivery epoch
> - PIP 104: Add new consumer type: TableView
> - PIP 106: Negative acknowledgment backoff
> - PIP 110: Topic customized metadata support
> - PIP 117: Change Pulsar standalone defaults
> - PIP 118: Do not restart brokers when ZooKeeper session expires
> - PIP 119: Enable consistent hashing by default on KeyShared dispatcher
> - PIP 120: Enable client memory limit by default
> - PIP 121: Pulsar cluster level auto failover
> - PIP 123: Pulsar metadata CLI tool
> - Metadata service batch operations
> - RocksDB metadata service backend
> - Etcd metadata service backend
> - Ack timeout redelivery backoff policy
> - Global topic policies
>
> Most of them have been completed, some work in progress we need to try to
> complete within 2 weeks.
> This can give me a 2 week buffer period to prepare for release and complete
> the release vote.
> For the unfinished parts, we can move them to 2.11.0.
>
> Some proposals are just being discussed, so I do not list them because I'm
> not sure if we can complete them in two weeks.
>
> You can find all the change lists from
>
> https://github.com/apache/pulsar/pulls?q=milestone%3A2.10.0+-label%3Arelease%2F2.9.1
> There are more than 500 commits.
>
> If I missed something or you have any suggestions please let me know.
>
> Regards,
> Penghui
>

Re: Sending 2.6 release line to EOF

[Dave Fisher]

This project VOTEs on more things than any Apache project I’ve been involved 
with during the last 14 years.

For most projects lazy consensus applies: 
https://www.apache.org/foundation/glossary.html#LazyConsensus

We also tend to “vote” during discussions which does not really advance a 
conversation.

If we want to have a VOTE then there are good reasons to start it NOW.

All the Best,
Dave

> On Jan 3, 2022, at 3:48 PM, Sijie Guo  wrote:
> 
> Agree to have a vote to keep a record.
> 
> - Sijie
> 
> On Mon, Jan 3, 2022 at 3:40 PM 陳智弘  wrote:
> 
>> I think having a vote and quickly announce the EOF of 2.6.x will be better
>> to the community.
>> 
>> 
>> Dave Fisher  於 2022年1月4日 週二 06:06 寫道：
>> 
>>> I don’t think we need a VOTE. Let’s do this by LAZY CONSENSUS.
>>> 
 On Jan 3, 2022, at 10:05 AM, Enrico Olivelli 
>>> wrote:
 
 Hello,
 We are no more cutting releases out of branch-2.6
 
 We must declare 2.6 EOF.
 
 IIUC there is no process established for this at the moment in the
>> Pulsar
 project.
 
 So for this time I will call out a VOTE next week, as we did not cut
 releases for a few important bugs.
 
 Thoughts?
 
 Enrico
>>> 
>>> 
>> 

[GitHub] [pulsar-helm-chart] wangshu3000 commented on a change in pull request #183: Update ingress api version, extension/v1beta1 will not be supported i…

[GitBox]

wangshu3000 commented on a change in pull request #183:
URL: https://github.com/apache/pulsar-helm-chart/pull/183#discussion_r70205



##
File path: charts/pulsar/templates/dashboard-ingress.yaml
##
@@ -19,7 +19,11 @@
 
 {{- if .Values.extra.dashboard }}
 {{- if .Values.dashboard.ingress.enabled }}
+{{- if semverCompare "<1.19-0" .Capabilities.KubeVersion.GitVersion }}

Review comment:
   @michaeljmarshall  Thanks for the feedback. 
   Looks like they changed the doc. I saw this from some examples of helm repo. 
Looks like it's been deprecated. The new value should be 
Capabilities.KubeVersion.Version
   
   There is one problem with .Capabilities.APIVersions.Has
   When someone use helm template command. It'll lock the kubernetes version to 
latest version in helm. So if they use new helm version 3.7+, there would 
always has the new api version even already specify the old kubenetes version 
in parameter. So the generated template yaml will have the new api version, 
when applying those yaml files, they will be failed in old kubernetes cluster. 
   
   I think maybe we should change to KubeVersion.Version as the 
KubeVersion.GitVersion has been deprecated.
   
   Please let me know if this make sense. 
   
   Thanks.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] wangshu3000 commented on a change in pull request #183: Update ingress api version, extension/v1beta1 will not be supported i…

[GitBox]

wangshu3000 commented on a change in pull request #183:
URL: https://github.com/apache/pulsar-helm-chart/pull/183#discussion_r71254



##
File path: charts/pulsar/templates/dashboard-ingress.yaml
##
@@ -19,7 +19,11 @@
 
 {{- if .Values.extra.dashboard }}
 {{- if .Values.dashboard.ingress.enabled }}
+{{- if semverCompare "<1.19-0" .Capabilities.KubeVersion.GitVersion }}

Review comment:
   https://github.com/argoproj/argo-cd/issues/3594
   This is the issue for your reference.
   There are some discussion around this.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSSION] PIP-132: Include message header size when check maxMessageSize of non-batch message on the client side.

[Zike Yang]

But how do we handle chunked messages? The chunked message is split
based on the maxMessageSize(max payload size). This would seem to make
`op.getMessageHeaderAndPayloadSize() > ClientCnx.getMaxMessageSize()`
always true.

Thanks,
Zike

On Fri, Dec 31, 2021 at 8:11 PM Haiting Jiang  wrote:
>
> Sorry, it should be PIP-132.
>
> Thanks,
> Haiting Jiang
>
> On 2021/12/31 12:05:54 Haiting Jiang wrote:
> > https://github.com/apache/pulsar/issues/13591
> >
> > Pasted below for quoting convenience.
> >
> > ——
> >
> > ## Motivation
> >
> > Currently, Pulsar client (Java) only checks payload size for max message 
> > size validation.
> >
> > Client throws TimeoutException if we produce a message with too many 
> > properties, see [1].
> > But the root cause is that is trigged TooLongFrameException in broker 
> > server.
> >
> > In this PIP, I propose to include message header size when check 
> > maxMessageSize of non-batch
> > messages, this brings the following benefits.
> > 1. Clients can throw InvalidMessageException immediately if properties 
> > takes too much storage space.
> > 2. This will make the behaviour consistent with topic level max message 
> > size check in broker.
> > 3. Strictly limit the entry size less than maxMessageSize, avoid sending 
> > message to bookkeeper failed.
> >
> > ## Goal
> >
> > Include message header size when check maxMessageSize for non-batch message 
> > on the client side.
> >
> > ## Implementation
> >
> > ```
> > // Add a size check in 
> > org.apache.pulsar.client.impl.ProducerImpl#processOpSendMsg
> > if (op.msg != null // for non-batch messages only
> > && op.getMessageHeaderAndPayloadSize() > ClientCnx.getMaxMessageSize()) 
> > {
> > // finish send op with InvalidMessageException
> > releaseSemaphoreForSendOp(op);
> > op.sendComplete(new PulsarClientException(new InvalidMessageException, 
> > op.sequenceId));
> > }
> >
> >
> > // 
> > org.apache.pulsar.client.impl.ProducerImpl.OpSendMsg#getMessageHeaderAndPayloadSize
> >
> > public int getMessageHeaderAndPayloadSize() {
> > ByteBuf cmdHeader = cmd.getFirst();
> > cmdHeader.markReaderIndex();
> > int totalSize = cmdHeader.readInt();
> > int cmdSize = cmdHeader.readInt();
> > int msgHeadersAndPayloadSize = totalSize - cmdSize - 4;
> > cmdHeader.resetReaderIndex();
> > return msgHeadersAndPayloadSize;
> > }
> > ```
> >
> > ## Reject Alternatives
> > Add a new property like "maxPropertiesSize" or "maxHeaderSize" in 
> > broker.conf and pass it to
> > client like maxMessageSize. But the implementation is much more complex, 
> > and don't have the
> > benefit 2 and 3 mentioned in Motivation.
> >
> > ## Compatibility Issue
> > As a matter of fact, this PIP narrows down the sendable range. Previously, 
> > when maxMessageSize
> > is 1KB, it's ok to send message with 1KB properties and 1KB payload. But 
> > with this PIP, the
> > sending will fail with InvalidMessageException.
> >
> > One conservative way is to add a boolean config "includeHeaderInSizeCheck" 
> > to enable this
> > feature. But I think it's OK to enable this directly as it's more 
> > reasonable, and I don't see good
> > migration plan if we add a config for this.
> >
> > The compatibility issue is worth discussing. And any suggestions are 
> > appreciated.
> >
> > [1] https://github.com/apache/pulsar/issues/13560
> >
> > Thanks,
> > Haiting Jiang
> >



-- 
Zike Yang

Re: [DISCUSSION] PIP-130: Apply redelivery backoff policy for ack timeout

[PengHui Li]

Looks there is no objection, I will start the official vote for PIP-130

Regards,
Penghui

On Fri, Dec 31, 2021 at 8:25 PM Haiting Jiang 
wrote:

> +1 for this PIP.
>
> Do we have plans for other languages clients? like go?
>
> Thanks,
> Haiting Jiang
>
> On 2021/12/27 13:24:52 PengHui Li wrote:
> > https://github.com/apache/pulsar/issues/13528
> >
> > Pasted below for quoting convenience.
> >
> > -
> >
> > PIP 130: Apply redelivery backoff policy for ack timeout
> >
> > ## Motivation
> >
> > PIP 106
> >
> https://github.com/apache/pulsar/wiki/PIP-106%3A-Negative-acknowledgment-backoff
> > introduced negative acknowledgment message redelivery backoff which
> allows
> > users to achieve
> > more flexible message redelivery delay time control. But the redelivery
> > backoff policy only
> > apply to the negative acknowledgment API, for users who use ack timeout
> to
> > trigger the message
> > redelivery, not the negative acknowledgment API, they can't use the new
> > features introduced by
> > PIP 106.
> >
> > So the proposal is to apply the message redelivery policy for the ack
> > timeout mechanism.
> > Users can specify an ack timeout redelivery backoff, for example, apply
> an
> > exponential backoff
> > with 10 seconds ack timeout:
> >
> > ```java
> > client.newConsumer()
> > .ackTimeout(10, TimeUnit.SECOND)
> > .ackTimeoutRedeliveryBackoff(
> > ExponentialRedeliveryBackoff.builder()
> > .minDelayMs(1000)
> > .maxDelayMs(6).build());
> > .subscribe();
> > ```
> >
> > The message redelivery behavior should be:
> >
> > |  Redelivery count   | Redelivery delay  |
> > |    |   |
> > | 1 | 10 + 1 seconds |
> > | 2 | 10 + 2 seconds |
> > | 3 | 10 + 4 seconds |
> > | 4 | 10 + 8 seconds |
> > | 5 | 10 + 16 seconds |
> > | 6 | 10 + 32 seconds |
> > | 7 | 10 + 60 seconds |
> > | 8 | 10 + 60 seconds |
> >
> > ## Goal
> >
> > Add an API to the Java Client to provide the ability to specify the ack
> > timeout message redelivery
> > backoff and the message redelivery behavior should abide by the
> redelivery
> > backoff policy.
> >
> >
> > ## API Changes
> >
> > 1. Change `NegativeAckRedeliveryBackoff` to `RedeliveryBackoff`, so that
> we
> > can use the
> > MessageRedeliveryBackoff for both negative acknowledgment API and ack
> > timeout message redelivery.
> >
> > 2. Change `NegativeAckRedeliveryExponentialBackoff` to
> > `ExponentialRedeliveryBackoff`, and add `multiplier`
> > for `RedeliveryExponentialBackoff` with default value 2.
> >
> > ExponentialRedeliveryBackoff.builder()
> > .minDelayMs(1000)
> > .maxDelayMs(6)
> > .multiplier(5)
> > .build()
> >
> > 3. Add `ackTimeoutRedeliveryBackoff` method for the `ConsumerBuilder`:
> >
> > ```java
> > client.newConsumer()
> > .ackTimeout(10, TimeUnit.SECOND)
> > .ackTimeoutRedeliveryBackoff(
> > ExponentialRedeliveryBackoff.builder()
> > .minDelayMs(1000)
> > .maxDelayMs(6).build());
> > .subscribe();
> > ```
> >
> > ## Compatibility and migration plan
> >
> > Since the negative acknowledgment message, redelivery backoff has not
> been
> > released yet,
> > so we can modify the API directly.
> >
> > ## Tests plan
> >
> > - Verify the introduced `multiplier` of ExponentialRedeliveryBackoff
> > - Verify the ack timeout message redelivery work as expected
> >
> > Regards,
> > Penghui
> >
>

[VOTE] PIP-130: Apply redelivery backoff policy for ack timeout

[PengHui Li]

This is the voting thread for PIP-130. It will stay open for at least 48
hours.

https://github.com/apache/pulsar/issues/13528

Pasted below for quoting convenience.

-

PIP 130: Apply redelivery backoff policy for ack timeout

## Motivation

PIP 106
https://github.com/apache/pulsar/wiki/PIP-106%3A-Negative-acknowledgment-backoff
introduced negative acknowledgment message redelivery backoff which allows
users to achieve
more flexible message redelivery delay time control. But the redelivery
backoff policy only
apply to the negative acknowledgment API, for users who use ack timeout to
trigger the message
redelivery, not the negative acknowledgment API, they can't use the new
features introduced by
PIP 106.

So the proposal is to apply the message redelivery policy for the ack
timeout mechanism.
Users can specify an ack timeout redelivery backoff, for example, apply an
exponential backoff
with 10 seconds ack timeout:

```java
client.newConsumer()
.ackTimeout(10, TimeUnit.SECOND)
.ackTimeoutRedeliveryBackoff(
ExponentialRedeliveryBackoff.builder()
.minDelayMs(1000)
.maxDelayMs(6).build());
.subscribe();
```

The message redelivery behavior should be:

|  Redelivery count   | Redelivery delay  |
|    |   |
| 1 | 10 + 1 seconds |
| 2 | 10 + 2 seconds |
| 3 | 10 + 4 seconds |
| 4 | 10 + 8 seconds |
| 5 | 10 + 16 seconds |
| 6 | 10 + 32 seconds |
| 7 | 10 + 60 seconds |
| 8 | 10 + 60 seconds |

## Goal

Add an API to the Java Client to provide the ability to specify the ack
timeout message redelivery
backoff and the message redelivery behavior should abide by the redelivery
backoff policy.


## API Changes

1. Change `NegativeAckRedeliveryBackoff` to `RedeliveryBackoff`, so that we
can use the
MessageRedeliveryBackoff for both negative acknowledgment API and ack
timeout message redelivery.

2. Change `NegativeAckRedeliveryExponentialBackoff` to
`ExponentialRedeliveryBackoff`, and add `multiplier`
for `RedeliveryExponentialBackoff` with default value 2.

ExponentialRedeliveryBackoff.builder()
.minDelayMs(1000)
.maxDelayMs(6)
.multiplier(5)
.build()

3. Add `ackTimeoutRedeliveryBackoff` method for the `ConsumerBuilder`:

```java
client.newConsumer()
.ackTimeout(10, TimeUnit.SECOND)
.ackTimeoutRedeliveryBackoff(
ExponentialRedeliveryBackoff.builder()
.minDelayMs(1000)
.maxDelayMs(6).build());
.subscribe();
```

## Compatibility and migration plan

Since the negative acknowledgment message, redelivery backoff has not been
released yet,
so we can modify the API directly.

## Tests plan

- Verify the introduced `multiplier` of ExponentialRedeliveryBackoff
- Verify the ack timeout message redelivery work as expected

Regards,
Penghui

Re: [VOTE] PIP-130: Apply redelivery backoff policy for ack timeout

[Haiting Jiang]

+1

Thanks,
Haiting Jiang

On 2022/01/04 03:34:33 PengHui Li wrote:
> This is the voting thread for PIP-130. It will stay open for at least 48
> hours.
> 
> https://github.com/apache/pulsar/issues/13528
> 
> Pasted below for quoting convenience.
> 
> -
> 
> PIP 130: Apply redelivery backoff policy for ack timeout
> 
> ## Motivation
> 
> PIP 106
> https://github.com/apache/pulsar/wiki/PIP-106%3A-Negative-acknowledgment-backoff
> introduced negative acknowledgment message redelivery backoff which allows
> users to achieve
> more flexible message redelivery delay time control. But the redelivery
> backoff policy only
> apply to the negative acknowledgment API, for users who use ack timeout to
> trigger the message
> redelivery, not the negative acknowledgment API, they can't use the new
> features introduced by
> PIP 106.
> 
> So the proposal is to apply the message redelivery policy for the ack
> timeout mechanism.
> Users can specify an ack timeout redelivery backoff, for example, apply an
> exponential backoff
> with 10 seconds ack timeout:
> 
> ```java
> client.newConsumer()
> .ackTimeout(10, TimeUnit.SECOND)
> .ackTimeoutRedeliveryBackoff(
> ExponentialRedeliveryBackoff.builder()
> .minDelayMs(1000)
> .maxDelayMs(6).build());
> .subscribe();
> ```
> 
> The message redelivery behavior should be:
> 
> |  Redelivery count   | Redelivery delay  |
> |    |   |
> | 1 | 10 + 1 seconds |
> | 2 | 10 + 2 seconds |
> | 3 | 10 + 4 seconds |
> | 4 | 10 + 8 seconds |
> | 5 | 10 + 16 seconds |
> | 6 | 10 + 32 seconds |
> | 7 | 10 + 60 seconds |
> | 8 | 10 + 60 seconds |
> 
> ## Goal
> 
> Add an API to the Java Client to provide the ability to specify the ack
> timeout message redelivery
> backoff and the message redelivery behavior should abide by the redelivery
> backoff policy.
> 
> 
> ## API Changes
> 
> 1. Change `NegativeAckRedeliveryBackoff` to `RedeliveryBackoff`, so that we
> can use the
> MessageRedeliveryBackoff for both negative acknowledgment API and ack
> timeout message redelivery.
> 
> 2. Change `NegativeAckRedeliveryExponentialBackoff` to
> `ExponentialRedeliveryBackoff`, and add `multiplier`
> for `RedeliveryExponentialBackoff` with default value 2.
> 
> ExponentialRedeliveryBackoff.builder()
> .minDelayMs(1000)
> .maxDelayMs(6)
> .multiplier(5)
> .build()
> 
> 3. Add `ackTimeoutRedeliveryBackoff` method for the `ConsumerBuilder`:
> 
> ```java
> client.newConsumer()
> .ackTimeout(10, TimeUnit.SECOND)
> .ackTimeoutRedeliveryBackoff(
> ExponentialRedeliveryBackoff.builder()
> .minDelayMs(1000)
> .maxDelayMs(6).build());
> .subscribe();
> ```
> 
> ## Compatibility and migration plan
> 
> Since the negative acknowledgment message, redelivery backoff has not been
> released yet,
> so we can modify the API directly.
> 
> ## Tests plan
> 
> - Verify the introduced `multiplier` of ExponentialRedeliveryBackoff
> - Verify the ack timeout message redelivery work as expected
> 
> Regards,
> Penghui
> 

Re: [DISCUSSION] PIP-132: Include message header size when check maxMessageSize of non-batch message on the client side.

[Haiting Jiang]

Good point,  I think we should shrink chunk size to 
"ClientCnx.getMaxMessageSize() - chunkMessageHeaderSize", as we have the same 
header size for each chunk message. 

Thanks,
Haiting Jiang

On 2022/01/04 03:27:00 Zike Yang wrote:
> But how do we handle chunked messages? The chunked message is split
> based on the maxMessageSize(max payload size). This would seem to make
> `op.getMessageHeaderAndPayloadSize() > ClientCnx.getMaxMessageSize()`
> always true.
> 
> Thanks,
> Zike
> 
> On Fri, Dec 31, 2021 at 8:11 PM Haiting Jiang  wrote:
> >
> > Sorry, it should be PIP-132.
> >
> > Thanks,
> > Haiting Jiang
> >
> > On 2021/12/31 12:05:54 Haiting Jiang wrote:
> > > https://github.com/apache/pulsar/issues/13591
> > >
> > > Pasted below for quoting convenience.
> > >
> > > ——
> > >
> > > ## Motivation
> > >
> > > Currently, Pulsar client (Java) only checks payload size for max message 
> > > size validation.
> > >
> > > Client throws TimeoutException if we produce a message with too many 
> > > properties, see [1].
> > > But the root cause is that is trigged TooLongFrameException in broker 
> > > server.
> > >
> > > In this PIP, I propose to include message header size when check 
> > > maxMessageSize of non-batch
> > > messages, this brings the following benefits.
> > > 1. Clients can throw InvalidMessageException immediately if properties 
> > > takes too much storage space.
> > > 2. This will make the behaviour consistent with topic level max message 
> > > size check in broker.
> > > 3. Strictly limit the entry size less than maxMessageSize, avoid sending 
> > > message to bookkeeper failed.
> > >
> > > ## Goal
> > >
> > > Include message header size when check maxMessageSize for non-batch 
> > > message on the client side.
> > >
> > > ## Implementation
> > >
> > > ```
> > > // Add a size check in 
> > > org.apache.pulsar.client.impl.ProducerImpl#processOpSendMsg
> > > if (op.msg != null // for non-batch messages only
> > > && op.getMessageHeaderAndPayloadSize() > 
> > > ClientCnx.getMaxMessageSize()) {
> > > // finish send op with InvalidMessageException
> > > releaseSemaphoreForSendOp(op);
> > > op.sendComplete(new PulsarClientException(new 
> > > InvalidMessageException, op.sequenceId));
> > > }
> > >
> > >
> > > // 
> > > org.apache.pulsar.client.impl.ProducerImpl.OpSendMsg#getMessageHeaderAndPayloadSize
> > >
> > > public int getMessageHeaderAndPayloadSize() {
> > > ByteBuf cmdHeader = cmd.getFirst();
> > > cmdHeader.markReaderIndex();
> > > int totalSize = cmdHeader.readInt();
> > > int cmdSize = cmdHeader.readInt();
> > > int msgHeadersAndPayloadSize = totalSize - cmdSize - 4;
> > > cmdHeader.resetReaderIndex();
> > > return msgHeadersAndPayloadSize;
> > > }
> > > ```
> > >
> > > ## Reject Alternatives
> > > Add a new property like "maxPropertiesSize" or "maxHeaderSize" in 
> > > broker.conf and pass it to
> > > client like maxMessageSize. But the implementation is much more complex, 
> > > and don't have the
> > > benefit 2 and 3 mentioned in Motivation.
> > >
> > > ## Compatibility Issue
> > > As a matter of fact, this PIP narrows down the sendable range. 
> > > Previously, when maxMessageSize
> > > is 1KB, it's ok to send message with 1KB properties and 1KB payload. But 
> > > with this PIP, the
> > > sending will fail with InvalidMessageException.
> > >
> > > One conservative way is to add a boolean config 
> > > "includeHeaderInSizeCheck" to enable this
> > > feature. But I think it's OK to enable this directly as it's more 
> > > reasonable, and I don't see good
> > > migration plan if we add a config for this.
> > >
> > > The compatibility issue is worth discussing. And any suggestions are 
> > > appreciated.
> > >
> > > [1] https://github.com/apache/pulsar/issues/13560
> > >
> > > Thanks,
> > > Haiting Jiang
> > >
> 
> 
> 
> -- 
> Zike Yang
> 

Voting time period minimum

[Dave Fisher]

The ASF considers that the minimum time for a vote is 72 hours for a few 
reasons particularly:

(1) to allow the world to spin. People are in most time zones.
(2) to allow for weekends.
(3) to allow time for contributors who are not working full time on the project.

Many projects use a 7 day vote. 

We just had 2 PIP votes called for 48 hours so this rule is worth reiterating!

All the best,
Dave

Sent from my iPhone

Re: Voting time period minimum

[Haiting Jiang]

Hi Dave,

The "48 hours" rule is on [1].
Maybe we should update the wiki and PIP template first?

[1] https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-%28PIP%29

On 2022/01/04 03:59:45 Dave Fisher wrote:
> The ASF considers that the minimum time for a vote is 72 hours for a few 
> reasons particularly:
> 
> (1) to allow the world to spin. People are in most time zones.
> (2) to allow for weekends.
> (3) to allow time for contributors who are not working full time on the 
> project.
> 
> Many projects use a 7 day vote. 
> 
> We just had 2 PIP votes called for 48 hours so this rule is worth reiterating!
> 
> All the best,
> Dave
> 
> Sent from my iPhone
> 


Thanks,
Haiting Jiang

Re: [DISCUSSION] PIP-131: Include message header size when check maxMessageSize of non-batch message on the client side.

[mattison chao]

Hi, @Jason918 
I think we can deprecate maxMessageSize to maxPayloadSize, and add 
maxHeaderSize to limit header size.
after then, we can use maxPayloadSize + maxHeaderSize to get maxMessageSize at 
internal.

What do you think about it?

> On Dec 31, 2021, at 8:05 PM, Haiting Jiang  wrote:
> 
> https://github.com/apache/pulsar/issues/13591
> 
> Pasted below for quoting convenience.
> 
> ——
> 
> ## Motivation
> 
> Currently, Pulsar client (Java) only checks payload size for max message size 
> validation.
> 
> Client throws TimeoutException if we produce a message with too many 
> properties, see [1].
> But the root cause is that is trigged TooLongFrameException in broker server.
> 
> In this PIP, I propose to include message header size when check 
> maxMessageSize of non-batch
> messages, this brings the following benefits.
> 1. Clients can throw InvalidMessageException immediately if properties takes 
> too much storage space.
> 2. This will make the behaviour consistent with topic level max message size 
> check in broker.
> 3. Strictly limit the entry size less than maxMessageSize, avoid sending 
> message to bookkeeper failed.
> 
> ## Goal
> 
> Include message header size when check maxMessageSize for non-batch message 
> on the client side.
> 
> ## Implementation
> 
> ```
> // Add a size check in 
> org.apache.pulsar.client.impl.ProducerImpl#processOpSendMsg
> if (op.msg != null // for non-batch messages only
>&& op.getMessageHeaderAndPayloadSize() > ClientCnx.getMaxMessageSize()) {
>// finish send op with InvalidMessageException
>releaseSemaphoreForSendOp(op);
>op.sendComplete(new PulsarClientException(new InvalidMessageException, 
> op.sequenceId));
> }
> 
> 
> // 
> org.apache.pulsar.client.impl.ProducerImpl.OpSendMsg#getMessageHeaderAndPayloadSize
> 
> public int getMessageHeaderAndPayloadSize() {
>ByteBuf cmdHeader = cmd.getFirst();
>cmdHeader.markReaderIndex();
>int totalSize = cmdHeader.readInt();
>int cmdSize = cmdHeader.readInt();
>int msgHeadersAndPayloadSize = totalSize - cmdSize - 4;
>cmdHeader.resetReaderIndex();
>return msgHeadersAndPayloadSize;
> }
> ```
> 
> ## Reject Alternatives
> Add a new property like "maxPropertiesSize" or "maxHeaderSize" in broker.conf 
> and pass it to 
> client like maxMessageSize. But the implementation is much more complex, and 
> don't have the 
> benefit 2 and 3 mentioned in Motivation.
> 
> ## Compatibility Issue
> As a matter of fact, this PIP narrows down the sendable range. Previously, 
> when maxMessageSize
> is 1KB, it's ok to send message with 1KB properties and 1KB payload. But with 
> this PIP, the 
> sending will fail with InvalidMessageException.
> 
> One conservative way is to add a boolean config "includeHeaderInSizeCheck" to 
> enable this 
> feature. But I think it's OK to enable this directly as it's more reasonable, 
> and I don't see good 
> migration plan if we add a config for this.
> 
> The compatibility issue is worth discussing. And any suggestions are 
> appreciated.
> 
> [1] https://github.com/apache/pulsar/issues/13560
> 
> Thanks,
> Haiting Jiang

Re: Voting time period minimum

[Dave Fisher]

Yes please! I did not notice that.

Personally I would be ok with 72 hours lazy consensus, but if we must vote then 
72 hours is a minimum.

Thanks,
Dave

Sent from my iPhone

> On Jan 3, 2022, at 8:10 PM, Haiting Jiang  wrote:
> 
> Hi Dave,
> 
> The "48 hours" rule is on [1].
> Maybe we should update the wiki and PIP template first?
> 
> [1] 
> https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-%28PIP%29
> 
>> On 2022/01/04 03:59:45 Dave Fisher wrote:
>> The ASF considers that the minimum time for a vote is 72 hours for a few 
>> reasons particularly:
>> 
>> (1) to allow the world to spin. People are in most time zones.
>> (2) to allow for weekends.
>> (3) to allow time for contributors who are not working full time on the 
>> project.
>> 
>> Many projects use a 7 day vote. 
>> 
>> We just had 2 PIP votes called for 48 hours so this rule is worth 
>> reiterating!
>> 
>> All the best,
>> Dave
>> 
>> Sent from my iPhone
>> 
> 
> 
> Thanks,
> Haiting Jiang

Re: Voting time period minimum

[Michael Marshall]

I agree that 72 hours should be the minimum.

For reference, this thread [0] from August 2021 proposed using 48
hours for the PIP voting period, and it explains why the wiki says 48
hours.

> (3) to allow time for contributors who are not working full time on the 
> project.

I think this point is crucial, especially when we have several votes
open at one time.

Thanks,
Michael

[0] https://lists.apache.org/thread/m8dr0hz7qn7rkd48bcp430lcq2q3674g

On Mon, Jan 3, 2022 at 10:17 PM Dave Fisher  wrote:
>
> Yes please! I did not notice that.
>
> Personally I would be ok with 72 hours lazy consensus, but if we must vote 
> then 72 hours is a minimum.
>
> Thanks,
> Dave
>
> Sent from my iPhone
>
> > On Jan 3, 2022, at 8:10 PM, Haiting Jiang  wrote:
> >
> > Hi Dave,
> >
> > The "48 hours" rule is on [1].
> > Maybe we should update the wiki and PIP template first?
> >
> > [1] 
> > https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-%28PIP%29
> >
> >> On 2022/01/04 03:59:45 Dave Fisher wrote:
> >> The ASF considers that the minimum time for a vote is 72 hours for a few 
> >> reasons particularly:
> >>
> >> (1) to allow the world to spin. People are in most time zones.
> >> (2) to allow for weekends.
> >> (3) to allow time for contributors who are not working full time on the 
> >> project.
> >>
> >> Many projects use a 7 day vote.
> >>
> >> We just had 2 PIP votes called for 48 hours so this rule is worth 
> >> reiterating!
> >>
> >> All the best,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
> >
> >
> > Thanks,
> > Haiting Jiang
>

Re: Warm Geetings on New Year 2022

[PengHui Li]

Thanks, yu

Happy new year!

Penghui
On Jan 4, 2022, 7:48 AM +0800, dev@pulsar.apache.org, wrote:
>
> t

Re: Sending 2.6 release line to EOF

[Michael Marshall]

I agree with Dave. Lazy consensus gives us exactly what we need: to
know if someone would like branch-2.6 to stay alive. If no one
responds that they need it within the time period, then no one needs
it.

PIP 47 briefly mentions our EOL policy, but the policy doesn't cover
our current case where we released fewer than 4 minor versions in a
year. I think we'd benefit from clarifying and improving our
documentation for our EOL policy.

> This project VOTEs on more things than any Apache project I’ve been involved 
> with during the last 14 years.

The new PIP process, with its increased purview, has increased the
number of votes. I have appreciated the increased development
discussion on the ML, but maybe the discussions (especially the ones
that look like votes) and then the subsequent votes are leading to the
high vote volume.

We could update the PIP process so that DISCUSSIONS without any
pushback during a certain time period do not need VOTES.

Thanks,
Michael


On Mon, Jan 3, 2022 at 6:00 PM Dave Fisher  wrote:
>
> This project VOTEs on more things than any Apache project I’ve been involved 
> with during the last 14 years.
>
> For most projects lazy consensus applies: 
> https://www.apache.org/foundation/glossary.html#LazyConsensus
>
> We also tend to “vote” during discussions which does not really advance a 
> conversation.
>
> If we want to have a VOTE then there are good reasons to start it NOW.
>
> All the Best,
> Dave
>
> > On Jan 3, 2022, at 3:48 PM, Sijie Guo  wrote:
> >
> > Agree to have a vote to keep a record.
> >
> > - Sijie
> >
> > On Mon, Jan 3, 2022 at 3:40 PM 陳智弘  wrote:
> >
> >> I think having a vote and quickly announce the EOF of 2.6.x will be better
> >> to the community.
> >>
> >>
> >> Dave Fisher  於 2022年1月4日 週二 06:06 寫道：
> >>
> >>> I don’t think we need a VOTE. Let’s do this by LAZY CONSENSUS.
> >>>
>  On Jan 3, 2022, at 10:05 AM, Enrico Olivelli 
> >>> wrote:
> 
>  Hello,
>  We are no more cutting releases out of branch-2.6
> 
>  We must declare 2.6 EOF.
> 
>  IIUC there is no process established for this at the moment in the
> >> Pulsar
>  project.
> 
>  So for this time I will call out a VOTE next week, as we did not cut
>  releases for a few important bugs.
> 
>  Thoughts?
> 
>  Enrico
> >>>
> >>>
> >>
>

[GitHub] [pulsar-helm-chart] michaeljmarshall commented on a change in pull request #183: Update ingress api version, extension/v1beta1 will not be supported i…

[GitBox]

michaeljmarshall commented on a change in pull request #183:
URL: https://github.com/apache/pulsar-helm-chart/pull/183#discussion_r777832255



##
File path: charts/pulsar/templates/dashboard-ingress.yaml
##
@@ -19,7 +19,11 @@
 
 {{- if .Values.extra.dashboard }}
 {{- if .Values.dashboard.ingress.enabled }}
+{{- if semverCompare "<1.19-0" .Capabilities.KubeVersion.GitVersion }}

Review comment:
   @wangshu3000 that definitely makes sense. I didn't know about the 
feature's shortcoming, thanks for sharing. Otherwise, do you need to update it 
to `KubeVersion.GitVersion` to `KubeVersion.Version`? We also need to figure 
out why CI hasn't run for this PR.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] wangshu3000 commented on a change in pull request #183: Update ingress api version, extension/v1beta1 will not be supported i…

[GitBox]

wangshu3000 commented on a change in pull request #183:
URL: https://github.com/apache/pulsar-helm-chart/pull/183#discussion_r777833010



##
File path: charts/pulsar/templates/dashboard-ingress.yaml
##
@@ -19,7 +19,11 @@
 
 {{- if .Values.extra.dashboard }}
 {{- if .Values.dashboard.ingress.enabled }}
+{{- if semverCompare "<1.19-0" .Capabilities.KubeVersion.GitVersion }}

Review comment:
   @michaeljmarshall  ok. let me do it.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on a change in pull request #192: [CI] Upgrade k8s to 1.18 and also upgrade helm, kind & chart releaser versions

[GitBox]

lhotari commented on a change in pull request #192:
URL: https://github.com/apache/pulsar-helm-chart/pull/192#discussion_r777846937



##
File path: .gitignore
##
@@ -16,3 +16,6 @@ charts/**/*.lock
 
 PRIVATEKEY
 PUBLICKEY
+.vagrant/
+pulsarctl-amd64-linux.tar.gz
+pulsarctl-amd64-linux/

Review comment:
   I updated .gitignore to cover pulsartcl-amd64-darwin




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on pull request #190: Bump to Pulsar 2.8.2

[GitBox]

lhotari commented on pull request #190:
URL: 
https://github.com/apache/pulsar-helm-chart/pull/190#issuecomment-1004554921


   > Also, why should we ship 2.8 as default instead of 2.9.1?
   
   I guess it could be about doing one step at a time (2.7.x -> 2.8.x, then 
2.8.x->2.9.x) and also about stability. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSSION] PIP-124: Create init subscription before sending message to DLQ

[Michael Marshall]

Before we get further into the implementation, I'd like to discuss
whether the current behavior is the expected behavior, as this is
the key motivation for this feature.

I think the DLQ's current behavior is the expected behavior because
the DLQ is only a topic and topics lose messages unless they have a
subscription or a retention policy.

I admit that it is not necessarily a nice default behavior to
potentially lose messages, but this is the design for all topics.
Based on the current design, an admin can create a retention policy
for the topic or namespace. Then, consumers of the
topic have the duration of the retention policy to discover the topic
and create a subscription before messages are lost. Is there a reason
this solution doesn't work for the DLQ topic?

Perhaps the disconnect here is that users of the DLQ feature do not
view the DLQ as only a Pulsar topic. I look forward to your thoughts.

As an aside, I wonder if topic discoverability is part of the problem
here. It would be extremely valuable to get notifications any
time a topic is created. That would allow users to move away from
polling for current topic names towards a more reactive design.

Thanks,
Michael


On Tue, Dec 28, 2021 at 7:59 PM Zike Yang
 wrote:
>
> > Oh, that's a very interesting point. I think it'd be easy to add that
> > as "internal" feature, though I'm a bit puzzled on how to add that to
> > the producer API
>
> I think we can add a field `String initialSubscriptionName` to the
> Producer Configuration. And add a new field `optional string
> initial_subscription_name` to the `CommnadProducer`.
> When the Broker handles the CommandProducer, if it checks that the
> initialSubscriptionName is not empty or null, it will use
> initialSubscriptionName to create a subscription on that topic. When
> creating the deadLetterProducer or retryLetterProducer, we can specify
> and create the initial subscription directly through the Producer.
> What do you think?
>
> On Thu, Dec 23, 2021 at 7:42 AM Matteo Merli  wrote:
> >
> > > What if we extended the `CommandProducer` command to add a
> > > `create_subscription` field? Then, any time a topic is auto
> > > created and this field is true, the broker would auto create a
> > > subscription. There are some details to work out, but I think this
> > > feature would fulfill the needs of this PIP and would also be broadly
> > > useful for many client applications that dynamically create topics.
> >
> > Oh, that's a very interesting point. I think it'd be easy to add that
> > as "internal" feature, though I'm a bit puzzled on how to add that to
> > the producer API
>
>
>
> --
> Zike Yang

[GitHub] [pulsar-helm-chart] michaeljmarshall closed issue #157: Ingresses still use the extensions/v1beta1 versioned resource

[GitBox]

michaeljmarshall closed issue #157:
URL: https://github.com/apache/pulsar-helm-chart/issues/157


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] michaeljmarshall merged pull request #183: Update ingress api version, extension/v1beta1 will not be supported i…

[GitBox]

michaeljmarshall merged pull request #183:
URL: https://github.com/apache/pulsar-helm-chart/pull/183


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org