lxd icon indicating copy to clipboard operation
lxd copied to clipboard

Adding a LXD cluster as a remote should store all addresses for the cluster

Open masnax opened this issue 1 year ago • 0 comments

When connecting to a LXD cluster via a remote registered with the lxc client, if the particular node whose address corresponds to the remote entry is down, then the cluster will be unreachable by that remote. What this would look like from the perspective of a consumer is that even though the cluster is still operational, it's unreachable until a configuration change is made if just one particular node goes down. The user would have to update the remote address to point to a different cluster member to be able to access the cluster again, or have multiple remotes registered and cycle through them.

In such a case I think LXD should be smart enough to know that the remote is a cluster and try to connect to other cluster addresses. Maybe this would involve supporting a list of addresses for remotes. Without making it super complicated, this could be user-specified when the remote is created.

We can also try to be clever about it and try to auto-detect when LXD is clustered. We'd probably have to try to connect to the remote when we create it, check if it's a clustered LXD, and fetch its cluster members to store their addresses on the client in ~/snap/lxd. We would also have to handle the client not having permission to view cluster members, in which case it would probably only keep the address that was explicitly given. One problem here is that the remote would still need to be manually updated if a new cluster member is added or if one is removed. To handle that case we would have to fetch the remote cluster members on each connection, which would be expensive. Another approach might be to have an endpoint that a client can use to fetch some data about the remote that it can store locally via lxc remote update mycluster or something similar.

masnax avatar Feb 06 '24 05:02 masnax