memcached charm doesn't open ufw on the right address

[Alvaro Uria]

When relating any service (ie: nova-cloud-controller) to memcached charm, private-address is used as memcached endpoint.

Other charms such as mysql and rabbitmq-server allow configuration of "access-network" parameter to force communication through specified network (ie: other than private-address).

In my specific case, private-address network is 1G while I'd like to specify a 10G network available.

Thank you.

[Nobuto Murata (nobuto)]

access-network or binding is really needed. In multi-network case, memcached charm setup ufw rules with unit private address. In this case, memcached only has connectivity to 192.168.123.X. nova-cloud-controller unit with 10.201.100.Y never be allowed to access to the memcached.

# ufw status verbose
Status: active
Logging: on (low)
Default: allow (incoming), allow (outgoing), deny (routed)
New profiles: skip

To Action From
-- ------ ----
11211/tcp ALLOW IN 192.168.123.X
11211/tcp ALLOW IN 192.168.123.X
11211/tcp ALLOW IN 10.201.100.Y
11211/tcp ALLOW IN 10.201.100.Y
11211/tcp ALLOW IN 10.201.100.Y
22 ALLOW IN Anywhere
11211/tcp DENY IN Anywhere
22 (v6) ALLOW IN Anywhere (v6)
11211/tcp (v6) DENY IN Anywhere (v6)

[Nobuto Murata (nobuto)]

Not sure it's appropriate to discuss my usecase in this bug, so opened a separate bug explicitly.
https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1684217

[Alex Kavanagh (ajkavanagh)]

I've got an mp in flight to add space bindings to the interfaces. See: https://code.launchpad.net/~ajkavanagh/charms/trusty/memcached/add-spaces-support/+merge/322844

[Jason Hobbs (jason-hobbs)]

It appears that this isn't actually fixed:

network-get shows that the bindings are set to the right value, but still for some reason ufw rules are being added for for the wrong network:

http://paste.ubuntu.com/26398199/

The 10.244.41.x IPs are from the right units, but are not the IPs on the 192.168.33.x network that we want.

From our bundle:
  memcached:
    charm: cs:xenial/memcached
    num_units: 2
    constraints: *oam-space-constr
    bindings:
      "": *internal-space
    options:
      allow-ufw-ip6-softfail: True
    to:
    - designate-bind/0
    - designate-bind/1

Our spaces:
Space Subnets
ceph-access-space 192.168.36.0/25
ceph-replica-space 192.168.35.0/25
external-space 10.244.32.0/21
internal-space 192.168.33.0/24
oam-space 10.244.40.0/21
undefined 10.245.208.0/20

[Jason Hobbs (jason-hobbs)]

To be clear, since our binding is on internal-space, the clients try to reach memcached on the IP for internal-space, not the IP in ufw. Disabling ufw allows access.

[Ashley Lai (alai)]

Any updates on this bug? This bug is on the "field high" list.

[Jason Hobbs (jason-hobbs)]

This bug is fixed; when I re-opened it, it was because I wasn't using the right binding from the other side of the relation.