When I deploy manila as a single unit, all is fine. If I use 3 units with vip and hacluster as shown in deployment guide, manila stays blocked
manila/0 blocked idle 4/lxd/4 10.0.2.90 8786/tcp Services not running that should be: manila-scheduler, manila-data; Ports which should be open, but are not: 8776
hacluster-manila/2 active idle 10.0.2.90 Unit is ready and clustered
manila/1 blocked idle 5/lxd/3 10.0.2.100 8786/tcp Services not running that should be: manila-scheduler, manila-data; Ports which should be open, but are not: 8776
hacluster-manila/1 active idle 10.0.2.100 Unit is ready and clustered
manila/2* blocked idle 6/lxd/3 10.0.2.95 8786/tcp Ports which should be open, but are not: 8776
hacluster-manila/0* active idle 10.0.2.95 Unit is ready and clustered
manila-ganesha is fine
Unit Workload Agent Machine Public address Ports Message
manila-ganesha/0* active idle 1/lxd/3 10.0.1.67 Unit is ready
hacluster-manila-ganesha/0* active idle 10.0.1.67 Unit is ready and clustered
manila-ganesha/1 active idle 2/lxd/4 10.0.1.69 Unit is ready
hacluster-manila-ganesha/2 active idle 10.0.1.69 Unit is ready and clustered
manila-ganesha/2 active idle 3/lxd/3 10.0.1.68 Unit is ready
hacluster-manila-ganesha/1 active idle 10.0.1.68 Unit is ready and clustered
If I ssh to units I can start manila-scheduler and manila-data manualy, but I cannot get rid of port error.
manila is listening on port 8786
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=152,fd=13))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=225,fd=3))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=225,fd=4))
LISTEN 0 128 [::1]:11211 [::]:* users:(("memcached",pid=46995,fd=26))
LISTEN 0 128 *:8786 *:* users:(("manila-api",pid=47062,fd=8),("manila-api",pid=47062,fd=7),("manila-api",pid=47061,fd=8),("manila-api",pid=47061,fd=7),("manila-api",pid=47060,fd=8),("manila-api",pid=47060,fd=7),("manila-api",pid=47059,fd=8),("manila-api",pid=47059,fd=7),("manila-api",pid=46977,fd=7))
for a comparison, when running single manila unit, it looks the same
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=152,fd=13))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=235,fd=3))
LISTEN 0 128 [::1]:11211 [::]:* users:(("memcached",pid=27493,fd=26))
LISTEN 0 128 *:8786 *:* users:(("manila-api",pid=27917,fd=8),("manila-api",pid=27917,fd=7),("manila-api",pid=27916,fd=8),("manila-api",pid=27916,fd=7),("manila-api",pid=27915,fd=8),("manila-api",pid=27915,fd=7),("manila-api",pid=27914,fd=8),("manila-api",pid=27914,fd=7),("manila-api",pid=27742,fd=7))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=235,fd=4))
manila:
charm: cs:manila
num_units: 3
options:
openstack-origin: *openstack-origin
vip: *manila-vip
# default-share-backend is a somewhat opaque configuration option
# that gets mapped into Manila's configuration file. The names are
# proscribed by the share type drivers in Manila. I suspect
# that we could remove this configuration, but the Manila charm
# currently goes into a blocked state without it set, and is broken
# if set incorrectly. In essence, to use CephFS with Ganesha, it must
# be set to cephfsnfs1
default-share-backend: cephfsnfs1
share-protocols: NFS
bindings:
"": *oam-space
public: *public-space
admin: *admin-space
internal: *internal-space
shared-db: *internal-space
to:
- lxd:1003
- lxd:1004
- lxd:1005
Hi Marian
Please could you add to the bug report:
- The bundle used for deploying the model.
- Any relevant logs from the affected units.
Many thanks