Test for router removed from cluster set can lead to false positive

[paulomach]

Steps to reproduce

1. Deploy mysql and mysql-router and a client app on vsphere/maas cloud
2. Relate all
3. edit mysql machine to remove line 127.0.1.1 from /etc/hosts file (workaround mysql-operator#433)

Expected behavior

Router should be able to connect to mysql

Actual behavior

Router fail with Router was manually removed from MySQL ClusterSet. Remove & re-deploy unit

Versions

mysql 8.0/edge
mysql-router dpe/edge

Juju CLI: 3.4.1

Additional context

The test is_router_in_cluster_set@src/workload.py fails due the router_id being different on cluster set metadata and router_id property.
On the cluster:

MySQL localhost:33060+ ssl Py> dba.get_cluster_set().list_routers()
{
    "domainName": "cluster-set-9e88628bbd1e5acae8de7e1021f36315", 
    "routers": {
        "juju-355e18-0.maas::system": 
...

on the router machine:

>>> socket.getfqdn()
'juju-355e18-0'

[github-actions]

https://warthogs.atlassian.net/browse/DPE-3984

[carlcsaposs-canonical]

3. edit mysql machine to remove line 127.0.1.1 from /etc/hosts file (workaround mysql-operator#433)

@paulomach is mysql router on the same machine as mysql? I'm wondering how editing /etc/hosts on mysql machine affects the router's id

[jamesbeedy]

@carlcsaposs-canonical , thanks for chiming in. I can confirm that removing the 127.0.1.1 line from /etc/hosts on the machine the router runs on is not a workaroud for this bug.

When the 127.0.1.1 line is removed from the router machine, socket.getfqdn() returns 192-168-7-122.maas :(

(Edited)

[jamesbeedy]

It is interesting to note that on the mysql host (also without the 127.0.1.1 line in /etc/hosts) that socket.getfqdn() returns juju-0fe1c3-0.maas 😕

[carlcsaposs-canonical]

@jamesbeedy what does socket.getfqdn() return on the router machine if /etc/hosts is unmodified? can you compare this to dba.get_cluster_set().list_routers()?