Re: [VOTE] Pulsar Release 2.8.0 Candidate 1

[Sijie Guo]

Enrico,

PR#10743 doesn't fix the problem and it actually made things worse. I am a
bit surprised that the change was merged without a review from other
committers who are more familiar with the Pulsar Functions codebase.

1) First of all, the problem can happen when you using an old version of a
broker to schedule functions with a new function docker image. In this way,
the new Functions will not able to run because the new Pulsar Functions
image is running under the `pulsar` user, which cannot read the token file
mounted under `root`.

2) During an upgrade process, people typically update the docker image
first before updating the function worker. The order is important here
because the command lines generated by the function worker are backward
compatible not forward compatible. If you update the function worker first,
it can easily break the running functions as the new function worker might
generate a command line that is not able to be recognized by the old
function image. So during an upgrade process, you would hit a similar issue
as 1).

3) PR#10743 didn't fix the problem. We used `400` for security concerns. We
want to limit the file to be only accessed by the user of the function
runner image. Changing 400 to 644 doesn't fix the problem. Instead, it
introduces other security concerns, because it makes the token file being
accessed by any users. A proper fix is to specify the proper `fsGroup` in
the security context of the functions pods.

4) I am not comfortable with rootless user change given the problem we have
identified. We should have proper fixes in place to address the permission
concerns before we switched to a rootless docker image. Because we also
don't know if it is going to break other changes or not.

Based on the concerns above, I believe the right approach here is to revert
#8796. We don't need to revert #10743. Because the user is `root` anyway.
But when we introduce the `rootless` change again, we need to remember to
change the permission from 644 to 400.

Let me know if you have any questions.

- Sijie


On Mon, Jun 7, 2021 at 10:48 PM Enrico Olivelli  wrote:

> Il Mar 8 Giu 2021, 03:32 PengHui Li  ha scritto:
>
> > Hi Sijie,
> >
> > Thanks for the feedback, cancel the RC1 for now.
> > Please don't vote for this thread again, thanks.
> >
> > This is the PR
> > https://github.com/apache/pulsar/pull/10861#pullrequestreview-678011678
> > for reverting https://github.com/apache/pulsar/pull/8796. After the PR
> > merged, I will send out the RC2 ASAP
> >
> > Penghui
> >
> > Sijie Guo  于2021年6月8日周二 上午9:26写道：
> >
> > > Penghui,
> > >
> > > Unfortunately, I think we have to cancel this vote.
> > >
> > > The change https://github.com/apache/pulsar/pull/8796 has broken the
> > > Pulsar
> > > Functions running on Kubernetes.
> > >
> > > The Pulsar Functions Kubernetes runtime generates a secret and mounts
> it
> > > using mode `256`. That means the secret is only able to read by the
> user.
> > > The StatefulSet created by Kubernetes runtime mounts the secrets under
> > the
> > > `root` user. Hence only the root user is able to read the secret. This
> > > results in any functions submitted will fail to read the authentication
> > > information.
> > >
> > > Because all the Kubernetes resources generated by the Kubernetes
> runtime
> > > are hardcoded. There is no easy way to change the security context for
> > the
> > > function statefulsets.
>
>
> Doesn't pr
> https://github.com/apache/pulsar/pull/10743
> Fix the problem?
>
> Can you share an error?
> Have you tracked the problem in a github issue?
>
> I am fine with reverting the patch
>
> But I am surprised because during the past days we (at Datastax) are
> testing the feature and we are able to run functions (apart from the
> problem, that I thought it was fixed by  #10743 )
>
> Enrico
>
>
> My take here is to revert the change in
> > > https://github.com/apache/pulsar/pull/8796 to go back to the root user
> > > until we address the issues in the Kubernetes runtime.
> > >
> > > If there are other approaches to get around this issue, please let me
> > know.
> > > Otherwise, we have to cancel this vote.
> > >
> > > - Sijie
> > >
> > > On Mon, Jun 7, 2021 at 4:02 PM PengHui Li  wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have also pushed the docker image to my personal dockerhub account.
> > > > If you want to verify on docker, you use use following images
> > > >
> > > > https://hub.docker.com/repository/docker/lph890127/pulsar
> > > > https://hub.docker.com/repository/docker/lph890127/pulsar-all
> > > > https://hub.docker.com/repository/docker/lph890127/pulsar-standalone
> > > >
> > > > Thanks,
> > > > Penghui
> > > >
> > > > Matteo Merli  于2021年6月8日周二 上午3:31写道：
> > > >
> > > > > +1 binding
> > > > >
> > > > > Checked:
> > > > >  * Signatures
> > > > >  * Bin distribution:
> > > > >  - NOTICE, README, LICENSE
> > > > >  - Start standalone service and producer/consumer test
> > > > >  * Src distribution:
> > > > >  - NOTICE

Correct TopicName#getPartitionIndex implementation

[Yunze Xu]

Hi all,

Currently the Java implementation to get the partition index of a topic name
is not correct. See
https://github.com/apache/pulsar/pull/8341/files#diff-445b0cfa56ca0c784df78e73d9294f2a37f079ca3c15c345b03c09d56f81ebff
 

 
for the unit tests I added.

I also noticed the problem in https://github.com/apache/pulsar/pull/10850 
 
because transaction buffer snapshot topic name may be `xxx-partition-0-yyy`,
which should not be treated as a partitioned topic.

Since Pulsar is 2.9.0-SNAPSHOT now, is it proper to correct the implementation?
What I concerned is the compatibility because we can’t assume users never used
a topic name like `my-topic-partition-000` to reference the partition 0 of
`my-topic`. If the behavior was corrected, `my-topic-partition-000` would be
treated as a non-partitioned topic.

I'm not sure if this change could have a wide influence, so I want to begin a
discussion about it.

Thanks,
Yunze

Re: [VOTE] Pulsar Release 2.8.0 Candidate 1

[Enrico Olivelli]

Il giorno mar 8 giu 2021 alle ore 09:22 Sijie Guo 
ha scritto:
>
> Enrico,
>
> PR#10743 doesn't fix the problem and it actually made things worse. I am a
> bit surprised that the change was merged without a review from other
> committers who are more familiar with the Pulsar Functions codebase.
>
> 1) First of all, the problem can happen when you using an old version of a
> broker to schedule functions with a new function docker image. In this way,
> the new Functions will not able to run because the new Pulsar Functions
> image is running under the `pulsar` user, which cannot read the token file
> mounted under `root`.
>
> 2) During an upgrade process, people typically update the docker image
> first before updating the function worker. The order is important here
> because the command lines generated by the function worker are backward
> compatible not forward compatible. If you update the function worker first,
> it can easily break the running functions as the new function worker might
> generate a command line that is not able to be recognized by the old
> function image. So during an upgrade process, you would hit a similar issue
> as 1).
>
> 3) PR#10743 didn't fix the problem. We used `400` for security concerns. We
> want to limit the file to be only accessed by the user of the function
> runner image. Changing 400 to 644 doesn't fix the problem. Instead, it
> introduces other security concerns, because it makes the token file being
> accessed by any users. A proper fix is to specify the proper `fsGroup` in
> the security context of the functions pods.
>
> 4) I am not comfortable with rootless user change given the problem we have
> identified. We should have proper fixes in place to address the permission
> concerns before we switched to a rootless docker image. Because we also
> don't know if it is going to break other changes or not.

We are on the same page.
We should think more about this change.
I raised other concerns about the lack of tools when you try to
operate on the pods (for instance you miss a text editor and netstat).

>
> Based on the concerns above, I believe the right approach here is to revert
> #8796. We don't need to revert #10743. Because the user is `root` anyway.
> But when we introduce the `rootless` change again, we need to remember to
> change the permission from 644 to 400.

Makes sense

>
> Let me know if you have any questions.

Very clear, thanks

The only thing I would add is to create a github issue in order to
track the upgrade issue and tell the story,
this way when we start a new implementation everyone will remember the
story and possibly we will write good integration tests

Enrico

>
> - Sijie
>
>
> On Mon, Jun 7, 2021 at 10:48 PM Enrico Olivelli  wrote:
>
> > Il Mar 8 Giu 2021, 03:32 PengHui Li  ha scritto:
> >
> > > Hi Sijie,
> > >
> > > Thanks for the feedback, cancel the RC1 for now.
> > > Please don't vote for this thread again, thanks.
> > >
> > > This is the PR
> > > https://github.com/apache/pulsar/pull/10861#pullrequestreview-678011678
> > > for reverting https://github.com/apache/pulsar/pull/8796. After the PR
> > > merged, I will send out the RC2 ASAP
> > >
> > > Penghui
> > >
> > > Sijie Guo  于2021年6月8日周二 上午9:26写道：
> > >
> > > > Penghui,
> > > >
> > > > Unfortunately, I think we have to cancel this vote.
> > > >
> > > > The change https://github.com/apache/pulsar/pull/8796 has broken the
> > > > Pulsar
> > > > Functions running on Kubernetes.
> > > >
> > > > The Pulsar Functions Kubernetes runtime generates a secret and mounts
> > it
> > > > using mode `256`. That means the secret is only able to read by the
> > user.
> > > > The StatefulSet created by Kubernetes runtime mounts the secrets under
> > > the
> > > > `root` user. Hence only the root user is able to read the secret. This
> > > > results in any functions submitted will fail to read the authentication
> > > > information.
> > > >
> > > > Because all the Kubernetes resources generated by the Kubernetes
> > runtime
> > > > are hardcoded. There is no easy way to change the security context for
> > > the
> > > > function statefulsets.
> >
> >
> > Doesn't pr
> > https://github.com/apache/pulsar/pull/10743
> > Fix the problem?
> >
> > Can you share an error?
> > Have you tracked the problem in a github issue?
> >
> > I am fine with reverting the patch
> >
> > But I am surprised because during the past days we (at Datastax) are
> > testing the feature and we are able to run functions (apart from the
> > problem, that I thought it was fixed by  #10743 )
> >
> > Enrico
> >
> >
> > My take here is to revert the change in
> > > > https://github.com/apache/pulsar/pull/8796 to go back to the root user
> > > > until we address the issues in the Kubernetes runtime.
> > > >
> > > > If there are other approaches to get around this issue, please let me
> > > know.
> > > > Otherwise, we have to cancel this vote.
> > > >
> > > > - Sijie
> > > >
> > > > On Mon, Jun 7, 2021 at 4:02 PM PengHui Li  wrote:
> > >

[VOTE] Pulsar Release 2.8.0 Candidate 2

[PengHui Li]

This is the second release candidate for Apache Pulsar, version 2.8.0.

It fixes the following issues:
https://github.com/apache/pulsar/pulls?q=is%3Apr+milestone%3A2.8.0+-label%3Arelease%2F2.7.1+-label%3Arelease%2F2.7.2+is%3Aclosed

*** Please download, test and vote on this release. This vote will stay open
for at least 72 hours ***

Note that we are voting upon the source (tag), binaries are provided for
convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.8.0-candidate-2/

SHA-512 checksums:

9f7304c3d35db97998a16a46362433c43c61d20eb3d2f51eb43175fa79728925175d4646c2cd72ad39fc614e425814af1b9a8a8635545cea291a28e28d57
apache-pulsar-2.8.0-SNAPSHOT-bin.tar.gz

8fe7e30c3cda0993114996dced0bf49986365a76bcc69b2e68160d6a9e52c9e9a2bc174eba7eb0c7467f6a62e009ee7d8a3457e0e46657ecf8f79f665549a176
apache-pulsar-2.8.0-SNAPSHOT-src.tar.gz

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1089/

The tag to be voted upon:
v2.8.0-candidate-2 (63126b9d6606863c1b889f75737623e1fa9e1638)
https://github.com/apache/pulsar/releases/tag/v2.8.0-candidate-2

Pulsar's KEYS file containing PGP keys we use to sign the release:
https://dist.apache.org/repos/dist/dev/pulsar/KEYS

Please download the the source package, and follow the README to build
and run the Pulsar standalone service.

Re: [VOTE] Pulsar Release 2.8.0 Candidate 2

[PengHui Li]

Sorry for the typo,

```
9f7304c3d35db97998a16a46362433c43c61d20eb3d2f51eb43175fa79728925175d4646c2cd72ad39fc614e425814af1b9a8a8635545cea291a28e28d57
apache-pulsar-2.8.0-SNAPSHOT-bin.tar.gz

8fe7e30c3cda0993114996dced0bf49986365a76bcc69b2e68160d6a9e52c9e9a2bc174eba7eb0c7467f6a62e009ee7d8a3457e0e46657ecf8f79f665549a176
apache-pulsar-2.8.0-SNAPSHOT-src.tar.gz
```

it should be

```
9f7304c3d35db97998a16a46362433c43c61d20eb3d2f51eb43175fa79728925175d4646c2cd72ad39fc614e425814af1b9a8a8635545cea291a28e28d57
apache-pulsar-2.8.0-bin.tar.gz

8fe7e30c3cda0993114996dced0bf49986365a76bcc69b2e68160d6a9e52c9e9a2bc174eba7eb0c7467f6a62e009ee7d8a3457e0e46657ecf8f79f665549a176
apache-pulsar-2.8.0-src.tar.gz
```

Thanks,
Penghui

PengHui Li  于2021年6月8日周二 下午6:37写道：

> This is the second release candidate for Apache Pulsar, version 2.8.0.
>
> It fixes the following issues:
>
> https://github.com/apache/pulsar/pulls?q=is%3Apr+milestone%3A2.8.0+-label%3Arelease%2F2.7.1+-label%3Arelease%2F2.7.2+is%3Aclosed
>
> *** Please download, test and vote on this release. This vote will stay
> open
> for at least 72 hours ***
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.8.0-candidate-2/
>
> SHA-512 checksums:
>
>
> 9f7304c3d35db97998a16a46362433c43c61d20eb3d2f51eb43175fa79728925175d4646c2cd72ad39fc614e425814af1b9a8a8635545cea291a28e28d57
> apache-pulsar-2.8.0-SNAPSHOT-bin.tar.gz
>
>
> 8fe7e30c3cda0993114996dced0bf49986365a76bcc69b2e68160d6a9e52c9e9a2bc174eba7eb0c7467f6a62e009ee7d8a3457e0e46657ecf8f79f665549a176
> apache-pulsar-2.8.0-SNAPSHOT-src.tar.gz
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1089/
>
> The tag to be voted upon:
> v2.8.0-candidate-2 (63126b9d6606863c1b889f75737623e1fa9e1638)
> https://github.com/apache/pulsar/releases/tag/v2.8.0-candidate-2
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
>
> Please download the the source package, and follow the README to build
> and run the Pulsar standalone service.
>

Re: [VOTE] Pulsar Release 2.8.0 Candidate 1

[Chris Bartholomew]

 I agree that using 'fsGroup' is the proper solution. 
If we are concerned about PR#10743 setting the permissions to 644 as a security 
risk, then why are we not also reverting it? If this is a legitimate problem, 
then are we not introducing a security risk in 2.8.0? Also, why not just revert 
it now so we don't have to remember to change it later and risk that we forget?
Cheers,Chris

On Tuesday, June 8, 2021, 03:22:07 AM EDT, Sijie Guo  
wrote:  
 
 Enrico,

PR#10743 doesn't fix the problem and it actually made things worse. I am a
bit surprised that the change was merged without a review from other
committers who are more familiar with the Pulsar Functions codebase.

1) First of all, the problem can happen when you using an old version of a
broker to schedule functions with a new function docker image. In this way,
the new Functions will not able to run because the new Pulsar Functions
image is running under the `pulsar` user, which cannot read the token file
mounted under `root`.

2) During an upgrade process, people typically update the docker image
first before updating the function worker. The order is important here
because the command lines generated by the function worker are backward
compatible not forward compatible. If you update the function worker first,
it can easily break the running functions as the new function worker might
generate a command line that is not able to be recognized by the old
function image. So during an upgrade process, you would hit a similar issue
as 1).

3) PR#10743 didn't fix the problem. We used `400` for security concerns. We
want to limit the file to be only accessed by the user of the function
runner image. Changing 400 to 644 doesn't fix the problem. Instead, it
introduces other security concerns, because it makes the token file being
accessed by any users. A proper fix is to specify the proper `fsGroup` in
the security context of the functions pods.

4) I am not comfortable with rootless user change given the problem we have
identified. We should have proper fixes in place to address the permission
concerns before we switched to a rootless docker image. Because we also
don't know if it is going to break other changes or not.

Based on the concerns above, I believe the right approach here is to revert
#8796. We don't need to revert #10743. Because the user is `root` anyway.
But when we introduce the `rootless` change again, we need to remember to
change the permission from 644 to 400.

Let me know if you have any questions.

- Sijie


On Mon, Jun 7, 2021 at 10:48 PM Enrico Olivelli  wrote:

> Il Mar 8 Giu 2021, 03:32 PengHui Li  ha scritto:
>
> > Hi Sijie,
> >
> > Thanks for the feedback, cancel the RC1 for now.
> > Please don't vote for this thread again, thanks.
> >
> > This is the PR
> > https://github.com/apache/pulsar/pull/10861#pullrequestreview-678011678
> > for reverting https://github.com/apache/pulsar/pull/8796. After the PR
> > merged, I will send out the RC2 ASAP
> >
> > Penghui
> >
> > Sijie Guo  于2021年6月8日周二 上午9:26写道：
> >
> > > Penghui,
> > >
> > > Unfortunately, I think we have to cancel this vote.
> > >
> > > The change https://github.com/apache/pulsar/pull/8796 has broken the
> > > Pulsar
> > > Functions running on Kubernetes.
> > >
> > > The Pulsar Functions Kubernetes runtime generates a secret and mounts
> it
> > > using mode `256`. That means the secret is only able to read by the
> user.
> > > The StatefulSet created by Kubernetes runtime mounts the secrets under
> > the
> > > `root` user. Hence only the root user is able to read the secret. This
> > > results in any functions submitted will fail to read the authentication
> > > information.
> > >
> > > Because all the Kubernetes resources generated by the Kubernetes
> runtime
> > > are hardcoded. There is no easy way to change the security context for
> > the
> > > function statefulsets.
>
>
> Doesn't pr
> https://github.com/apache/pulsar/pull/10743
> Fix the problem?
>
> Can you share an error?
> Have you tracked the problem in a github issue?
>
> I am fine with reverting the patch
>
> But I am surprised because during the past days we (at Datastax) are
> testing the feature and we are able to run functions (apart from the
> problem, that I thought it was fixed by  #10743 )
>
> Enrico
>
>
> My take here is to revert the change in
> > > https://github.com/apache/pulsar/pull/8796 to go back to the root user
> > > until we address the issues in the Kubernetes runtime.
> > >
> > > If there are other approaches to get around this issue, please let me
> > know.
> > > Otherwise, we have to cancel this vote.
> > >
> > > - Sijie
> > >
> > > On Mon, Jun 7, 2021 at 4:02 PM PengHui Li  wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have also pushed the docker image to my personal dockerhub account.
> > > > If you want to verify on docker, you use use following images
> > > >
> > > > https://hub.docker.com/repository/docker/lph890127/pulsar
> > > > https://hub.docker.com/repository/docker/lph8901

[GitHub] [pulsar-helm-chart] uiot-stack commented on issue #124: pulsar waiting to start: PodInitializing

[GitBox]

uiot-stack commented on issue #124:
URL: 
https://github.com/apache/pulsar-helm-chart/issues/124#issuecomment-857319583


   I have the some issue


-- 
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.

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

Re: [VOTE] Pulsar Release 2.8.0 Candidate 2

[Matteo Merli]

+1 binding

Checked:
 * Signatures
 * Bin distribution:
 - NOTICE, README, LICENSE
 - Start standalone service and producer/consumer test
 * Src distribution:
 - NOTICE,  README, LICENSE
 - Compile and unit tests
 - Start standalone service
 * Checked staging maven repository artifacts


--
Matteo Merli


On Tue, Jun 8, 2021 at 3:59 AM PengHui Li  wrote:
>
> Sorry for the typo,
>
> ```
> 9f7304c3d35db97998a16a46362433c43c61d20eb3d2f51eb43175fa79728925175d4646c2cd72ad39fc614e425814af1b9a8a8635545cea291a28e28d57
> apache-pulsar-2.8.0-SNAPSHOT-bin.tar.gz
>
> 8fe7e30c3cda0993114996dced0bf49986365a76bcc69b2e68160d6a9e52c9e9a2bc174eba7eb0c7467f6a62e009ee7d8a3457e0e46657ecf8f79f665549a176
> apache-pulsar-2.8.0-SNAPSHOT-src.tar.gz
> ```
>
> it should be
>
> ```
> 9f7304c3d35db97998a16a46362433c43c61d20eb3d2f51eb43175fa79728925175d4646c2cd72ad39fc614e425814af1b9a8a8635545cea291a28e28d57
> apache-pulsar-2.8.0-bin.tar.gz
>
> 8fe7e30c3cda0993114996dced0bf49986365a76bcc69b2e68160d6a9e52c9e9a2bc174eba7eb0c7467f6a62e009ee7d8a3457e0e46657ecf8f79f665549a176
> apache-pulsar-2.8.0-src.tar.gz
> ```
>
> Thanks,
> Penghui
>
> PengHui Li  于2021年6月8日周二 下午6:37写道：
>
> > This is the second release candidate for Apache Pulsar, version 2.8.0.
> >
> > It fixes the following issues:
> >
> > https://github.com/apache/pulsar/pulls?q=is%3Apr+milestone%3A2.8.0+-label%3Arelease%2F2.7.1+-label%3Arelease%2F2.7.2+is%3Aclosed
> >
> > *** Please download, test and vote on this release. This vote will stay
> > open
> > for at least 72 hours ***
> >
> > Note that we are voting upon the source (tag), binaries are provided for
> > convenience.
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.8.0-candidate-2/
> >
> > SHA-512 checksums:
> >
> >
> > 9f7304c3d35db97998a16a46362433c43c61d20eb3d2f51eb43175fa79728925175d4646c2cd72ad39fc614e425814af1b9a8a8635545cea291a28e28d57
> > apache-pulsar-2.8.0-SNAPSHOT-bin.tar.gz
> >
> >
> > 8fe7e30c3cda0993114996dced0bf49986365a76bcc69b2e68160d6a9e52c9e9a2bc174eba7eb0c7467f6a62e009ee7d8a3457e0e46657ecf8f79f665549a176
> > apache-pulsar-2.8.0-SNAPSHOT-src.tar.gz
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachepulsar-1089/
> >
> > The tag to be voted upon:
> > v2.8.0-candidate-2 (63126b9d6606863c1b889f75737623e1fa9e1638)
> > https://github.com/apache/pulsar/releases/tag/v2.8.0-candidate-2
> >
> > Pulsar's KEYS file containing PGP keys we use to sign the release:
> > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> >
> > Please download the the source package, and follow the README to build
> > and run the Pulsar standalone service.
> >

[GitHub] [pulsar-manager] karankardas opened a new issue #396: where is SPRING_CONFIGURATION_FILE: /pulsar-manager/pulsar-manager/application.properties

[GitBox]

karankardas opened a new issue #396:
URL: https://github.com/apache/pulsar-manager/issues/396


   I have used docker-compose file.
   `version: "3.7"
   services:
 pulsar:
   image: apachepulsar/pulsar
   command: bin/pulsar standalone
   hostname: pulsar
   ports:
 - "8080:8080"
 - "6650:6650"
   restart: unless-stopped
   volumes:
 - "./data/:/pulsar/data"
 dashboard:
   image: apachepulsar/pulsar-manager:v0.2.0
   ports:
 - "9527:9527"
 - "7750:7750"
   depends_on:
 - pulsar
   links:
 - pulsar
   environment:
 SPRING_CONFIGURATION_FILE: 
/pulsar-manager/pulsar-manager/application.properties`
   
   can anyone tell me where is application.properties file please ?
   
   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.

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