[Bug]: In TLS env milvus client breaking healthCheck() if not configured database name in clientConfig

[manishkuri]

Is there an existing issue for this?

• I have searched the existing issues

Environment

- Milvus version: 2.3.11
- Deployment mode(standalone or cluster):cluster
- MQ type(rocksmq, pulsar or kafka):    
- SDK version(e.g. pymilvus v2.0.0rc2): 2.4.5
- OS(Ubuntu or CentOS): CentOS
- CPU/Memory: 
- GPU: 
- Others:

Current Behavior

In case of TLS disabled env, Attu connects with Milvus without asking for dbName But

When we make a call from Attu to Milvus in a TLS-enabled env, Attu breaks on milvusClient.healthCheck().
here - https://github.com/zilliztech/attu/blob/6fb43dab943630304d69efe384d0ea260183b3a3/server/src/milvus/milvus.service.ts#L72
in this case, when I also pass the dbName in clientConfig during the Attu call, it successfully connects with it.

changes added to attu code:

if (process.env.DB_NAME) {
          clientConfig.database = process.env.DB_NAME;
        }
```,

### Expected Behavior

As going through the client code in Milvus-sdk, dbName is optional. 
so by default, it should connect with any one of the active db and also bring up other db's in UI to enter

### Steps To Reproduce

```markdown
1. Create a client request in TLS-enabled env to Milvus without passing the dbName in the client config

Milvus Log

No response

Anything else?

No response

[binbinlv]

/assign @Presburger

[binbinlv]

/unassign @yanliang567

[xiaofan-luan]

/assign @SimFG

[SimFG]

@manishkuri Is there any error message when the database is not set?

[manishkuri]

@SimFG io.grpc.StatusRuntimeException: UNIMPLEMENTED

[SimFG]

@manishkuri can you show the whole error message? And are you using the v2.3.11 milvus, what version of attu did you use?

[manishkuri]

so I was calling it via Attu and getting an error msg: 'Milvus is not ready yet.'
from this line. Attu version : 2.4 (edited)
https://github.com/zilliztech/attu/blob/6fb43dab943630304d69efe384d0ea260183b3a3/server/src/milvus/milvus.service.ts#L76

[xiaofan-luan]

the attu version might be too old right?

I would say you should use attu with 2.3.x or 2.4.x

[manishkuri]

@xiaofan-luan sorry for the earlier wrong info, I was using Attu version v2.4

[SimFG]

@manishkuri Can you upload the proxy node log when the error occurs?

[manishkuri]

@SimFG
io.grpc.StatusRuntimeException: UNIMPLEMENTED
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:271) ~[grpc-stub-1.46.0.jar:1.46.0]
at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:252) ~[grpc-stub-1.46.0.jar:1.46.0]
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:165) ~[grpc-stub-1.46.0.jar:1.46.0]
at io.milvus.grpc.MilvusServiceGrpc$MilvusServiceBlockingStub.hasCollection(MilvusServiceGrpc.java:4453) ~[milvus-sdk-java-2.3.3.jar:?]
at io.milvus.client.AbstractMilvusGrpcClient.hasCollection(AbstractMilvusGrpcClient.java:353) ~[milvus-sdk-java-2.3.3.jar:?]
at io.milvus.client.MilvusServiceClient.lambda$hasCollection$1(MilvusServiceClient.java:305) ~[milvus-sdk-java-2.3.3.jar:?]
at io.milvus.client.MilvusServiceClient.retry(MilvusServiceClient.java:256) [milvus-sdk-java-2.3.3.jar:?]
at io.milvus.client.MilvusServiceClient.hasCollection(MilvusServiceClient.java:305) [milvus-sdk-java-2.3.3.jar:?]
at MilvusJavaClient.main(MilvusJavaClient.java:848) [classes/:?]

[xiaofan-luan]

@manishkuri
can you offer your serverside error as well? with
https://github.com/milvus-io/milvus/tree/master/deployments/export-log

[SimFG]

It's a bit strange, why does the java-sdk stack appear when using attu? In addition, the version of this sdk seems to be relatively old, which is 2.3.3

[manishkuri]

@SimFG above request I hit directly via SDK client without dbName. I think it will create same scenario.

[xiaofan-luan]

from the java sdk, we don't support any kind of db operation right now.

@yhmo can you double confirm

[xiaofan-luan]

but I'm also confused since attu is using nodejs client but your test seems to be running on java

[yhmo]

In milvus, there is always a default database named "default". All the sdks are using the default db name to connect, including python/java/nodejs sdk. The Attu is using nodejs sdk.

So, if you didn't specify a database name, no matter what kind of sdk, the client will use the "default" db name to connect, it should be ok to work.

I just tested your use case, and I didn't get the error you encountered. Please look at my test workflow to see if there is any difference from yours.

• Firstly I create some certificate files by following the steps in this document: https://milvus.io/docs/tls.md
  The certificate files are generated in my local under this path: /home/yhmo/work/git-go/pymilvus/examples/tls

• Secondly, I start a Milvus v2.3.11 standalone by docker-compose
  The docker-component.yaml

  standalone:
    container_name: milvus-standalone
    image: milvusdb/milvus:v2.3.11
    ......
    volumes:
      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
      - ${DOCKER_VOLUME_DIRECTORY:-.}/milvus.yaml:/milvus/configs/milvus.yaml
      - /home/yhmo/work/git-go/pymilvus/examples/tls:/milvus/tls

The milvus.yaml

tls:
  serverPemPath: /milvus/tls/server.pem
  serverKeyPath: /milvus/tls/server.key
  caPemPath: /milvus/tls/ca.pem

common:
  security:
    tlsMode: 2

• Use different SDK to connect the server
  By pymilvus, no problem.

milvus_client = MilvusClient(uri=_URI,
                            client_pem_path="/home/yhmo/work/git-go/pymilvus/examples/tls/client.pem",
                            client_key_path="/home/yhmo/work/git-go/pymilvus/examples/tls/client.key",
                            ca_pem_path="/home/yhmo/work/git-go/pymilvus/examples/tls/ca.pem",
                            server_name='localhost')
print(milvus_client.list_collections())

By Java SDK v2.3.3, no problem.

ConnectParam connectParam = ConnectParam.newBuilder()
        .withHost("localhost")
        .withPort(19530)
        .withServerName("localhost")
        .withCaPemPath("/home/yhmo/work/git-go/pymilvus/examples/tls/ca.pem")
        .withClientKeyPath("/home/yhmo/work/git-go/pymilvus/examples/tls/client.key")
        .withClientPemPath("/home/yhmo/work/git-go/pymilvus/examples/tls/client.pem")
        .withDatabaseName("default")
        .build();
MilvusServiceClient milvusClient = new MilvusServiceClient(connectParam);

R<CheckHealthResponse> health = milvusClient.checkHealth();
if (health.getStatus() != R.Status.Success.getCode()) {
    throw new RuntimeException(health.getMessage());
}

• Start an Attu v2.4.0 webserver to connect the milvus server

docker run -p 8000:3000 \
    -v /home/yhmo/work/git-go/pymilvus/examples/tls:/app/tls \
    -e ATTU_LOG_LEVEL=info  \
    -e ROOT_CERT_PATH=/app/tls/ca.pem \
    -e PRIVATE_KEY_PATH=/app/tls/client.key \
    -e CERT_CHAIN_PATH=/app/tls/client.pem \
    -e SERVER_NAME=localhost \
    zilliz/attu:v2.4.0

The database name is "default", it connects successfully. Even if I set the database name to be "" (an empty string), it also connects successfully.

[manishkuri]

Then our Istio virtual service might be doing something bad here. let me check

[manishkuri]

@yanliang567 , @xiaofan-luan , @SimFG It's in our istio service routing logic. we made it mandatory to have a dbName in the header. Keeping an optional dbName in case of tls case will fix our issue. Please help us reviewing or merging this pr - zilliztech/attu#641

[SimFG]

@manishkuri @shanghaikid please help to check it.

[xiaofan-luan]

@shanghaikid is helping on the review

[manishkuri]

thanks!