memcached and nova-cc relation sets up incorrect ufw rules in multi-network env
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Nova Cloud Controller Charm |
Triaged
|
Low
|
Unassigned | ||
memcached-charm |
Won't Fix
|
Low
|
Unassigned |
Bug Description
Not sure where is the upstream branch of memcached charm, but the revision in charm store relies on relation_
That ends up with unexpected ufw rules in multi-network environment. For example, if memcached only has 192.168.0.0/24 network and nova-cc has 192.168.0.0/24 and 10.0.0.0/24 networks. An IP adddress from 10.0.0.0/24 will be chosen as unit private address and will be written, but nova-cc will access to memcached from 192.168.0.0/24. So no allowed rules in ufw will match.
It would be nice if memcached relation supported network bindings to detect the correct IP addresses for ufw rules reliably.
# 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 10.0.0.XY
22 ALLOW IN Anywhere
11211/tcp DENY IN Anywhere
22 (v6) ALLOW IN Anywhere (v6)
11211/tcp (v6) DENY IN Anywhere (v6)
[hooks/
@hooks.
def cache_relation_
settings = {'host': unit_get(
for rid in relation_
addr = relation_
if addr:
Changed in charm-nova-cloud-controller: | |
importance: | Medium → Low |
Changed in memcached (Juju Charms Collection): | |
importance: | Medium → Low |
no longer affects: | memcached (Juju Charms Collection) |
Changed in charm-memcached: | |
importance: | Undecided → Low |
status: | New → Won't Fix |
status: | Won't Fix → Fix Released |
Changed in charm-memcached: | |
status: | Fix Released → Won't Fix |
Having compared diffs of the downloadable zip from the charm store and lp:charms/trusty/memcached, I can confirm that they are identical. This probably means that lp:charms/memcached should be brought up to date to the trusy/memcached branch too.