[Bug]: Wrong port used to access Pulsar in test files

[Ald392]

Is there an existing issue for this?

• I have searched the existing issues

Environment

No response

Current Behavior

When go tests are conducted inside milvus/pkg/mq/msgstream/mqwrapper/pulsar, following errors are occurring:

Expected Behavior

No response

Steps To Reproduce

1. Run the go test following steps inside DEVELOPMENT.md

Milvus Log

No response

Anything else?

No response

[Ald392]

Reason: Inside

milvus/deployments/docker/dev/docker-compose.yml

Line 38 in 70e3d5b

- "18080:8080"

Pulsar containers port 8080 is mapped to localhosts port 18080. But in :

1. milvus/pkg/mq/msgstream/mqwrapper/pulsar/pulsar_client_test.go

   Line 753 in 70e3d5b

   webServiceURL = "http://" + pulsarURL.Hostname() + ":" + "8080"

2. milvus/pkg/mq/msgstream/mqwrapper/pulsar/pulsar_consumer_test.go

   Line 185 in 70e3d5b

   webServiceURL = "http://" + pulsarURL.Hostname() + ":" + "8080"

the new pulsar admin client is giving requests to port 8080 of localhost.

Solution:
Changing port number to 18080 in both can solve the issue

[xiaofan-luan]

that is based on your deployment right?
By default it is 8080 but it's kind like based on your deployment.

The tricky part here is for pulsarctl, they have two ports 80 and 8080 by default, based on whether you have a proxy deployed

[xiaofan-luan]

but 18080 is definitely your internal definition I guess

[yanliang567]

/assign @Ald392
please help to check as comments above.

/unassign

[Ald392]

but 18080 is definitely your internal definition I guess

Port 8080 of pulsar container is forwarded to localhosts port 18080 in the milvus/deployments/docker/dev/docker-compose.yml
Which is the recommended deployment for UT according to https://github.com/milvus-io/milvus/blob/e19d17076f21183883fc8acd648e1a112f8c42fb/DEVELOPMENT.md

So either we have to change the port used to access pulsar in go test files or we have to forward pulsar's 8080 to localhosts 8080 which when i tested was causing some new test failures. Because some other go tests are running on assumption that localhosts 8080 is free. I believe that is the reason for forwarding pulsar to localhosts 18080 in the first place.
So the preferred solution according to me would be to change port used for accessing pulsar in test files to 18080.

[xiaofan-luan]

Port 8080 of pulsar container is forwarded to localhosts port 18080 in the milvus/deployments/docker/dev/docker-compose.yml Which is the recommended deployment for UT according to https://github.com/milvus-io/milvus/blob/e19d17076f21183883fc8acd648e1a112f8c42fb/DEVELOPMENT.md

So either we have to change the port used to access pulsar in go test files or we have to forward pulsar's 8080 to localhosts 8080 which when i tested was causing some new test failures. Because some other go tests are running on assumption that localhosts 8080 is free. I believe that is the reason for forwarding pulsar to localhosts 18080 in the first place. So the preferred solution according to me would be to change port used for accessing pulsar in test files to 18080.

But I thought not all the user are running with the pod forward? Should it just be changed based on users requirment?

[Ald392]

Port 8080 of pulsar container is forwarded to localhosts port 18080 in the milvus/deployments/docker/dev/docker-compose.yml Which is the recommended deployment for UT according to https://github.com/milvus-io/milvus/blob/e19d17076f21183883fc8acd648e1a112f8c42fb/DEVELOPMENT.md
So either we have to change the port used to access pulsar in go test files or we have to forward pulsar's 8080 to localhosts 8080 which when i tested was causing some new test failures. Because some other go tests are running on assumption that localhosts 8080 is free. I believe that is the reason for forwarding pulsar to localhosts 18080 in the first place. So the preferred solution according to me would be to change port used for accessing pulsar in test files to 18080.

But I thought not all the user are running with the pod forward? Should it just be changed based on users requirment?

Ok, that would be enough. But the scenario should be informed to the user right?
Also another thing to add is that i have observed these tests are passing in the GO ut pipeline. Are we using a different docker-compose file there, if so is there any link to that?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Rotten issues close after 30d of inactivity. Reopen the issue with /reopen.