swift-storage charm not network-space aware
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Swift Proxy Charm |
Fix Released
|
Medium
|
James Page | ||
OpenStack Swift Storage Charm |
Fix Released
|
Medium
|
James Page |
Bug Description
I have a juju-deployer config such as:
swift-
charm: swift-storage
bindings:
"": space-mgmt
ceph-osd:
charm: ceph-osd
bindings:
public: space-sta
cluster: space-stc
"": space-mgmt
swift-proxy:
charm: swift-proxy
bindings:
"": space-mgmt
public: space-api
admin: space-mgmt
internal: space-mgmt
All charms are 17.02 version.
ceph-osd and swift-storage-z1 both land on metal with all spaces defined with IPs in MAAS 2.x.
Let's say space-mgmt is 10.116.24.0/21, space-api is 20.30.40.0/25, space-sta is 10.116.166.0/23 and space-stc is 10.116.0.0/24.
So, my swift-storage.z1/0 host has IPs:
10.116.24.2
20.30.40.2
10.116.166.2
10.116.0.2
my swift-proxy/0 unit is running in an LXD with ips
10.116.24.3
20.30.40.3
When running add-relation swift-storage-z1 swift-proxy, swift-proxy is receiving relation_
I would expect that with bindings aware code in juju 2.1.3, that the swift-storage-z1/0 unit would be assigned private-address within juju's core code of the ip on space-mgmt as the default binding for the service/
Changed in charm-swift-storage: | |
milestone: | 18.02 → 17.11 |
Changed in charm-swift-proxy: | |
milestone: | 18.02 → 17.11 |
assignee: | nobody → James Page (james-page) |
Changed in charm-swift-storage: | |
status: | Fix Committed → Fix Released |
Changed in charm-swift-proxy: | |
status: | Fix Committed → Fix Released |
per Billy Olsen, charm-swift-storage is not space-aware. Going to try work-around of encapsulating in an LXD to separate IP namespaces for this service.