Charm Helpers

Merge lp://qastaging/~james-page/charm-helpers/get_network_addresses-refactor into lp://qastaging/charm-helpers

get_network_addresses-refactor
Merge into devel

Proposed by James Page on 2017-08-07

Status:	Merged
Merged at revision:	780
Proposed branch:	lp://qastaging/~james-page/charm-helpers/get_network_addresses-refactor
Merge into:	lp://qastaging/charm-helpers
Diff against target:	573 lines (+137/-347) 2 files modified charmhelpers/contrib/openstack/context.py (+25/-32) tests/contrib/openstack/test_os_contexts.py (+112/-315)
To merge this branch:	bzr merge lp://qastaging/~james-page/charm-helpers/get_network_addresses-refactor
Related bugs:	Link a bug report

Reviewer	Date Requested	Status
David Ames (community)		Approve on 2017-08-08
Alex Kavanagh	2017-08-07	Approve on 2017-08-07
Review via email: mp+328648@code.qastaging.launchpad.net

Description of the change

Misc refactoring to support network spaces for Apache SSL support in the
openstack charms.

Revision history for this message

Alex Kavanagh (ajkavanagh) wrote on 2017-08-07:

I'd also like David (thedac) to review this as he's spent a lot of time in this area recently.

review: Approve

Revision history for this message

James Page (james-page) wrote on 2017-08-07:

I think this code path is also a potential trip hazard for the dual-stack endpoint work that thedac is looking at - specifically combined with HTTPS; the code forces virtual host binding to specific network addresses and there is no concept of 'multiple addresses per endpoint' at the moment.

Revision history for this message

David Ames (thedac) wrote on 2017-08-08:

James,

Sorry for the long delay on this. I have finally completed some testing. My original concern was the removal of vip information. But I have proven to myself that
endpoint = resolve_address(net_type)
Does the right thing.

Approved. Merging.

I'll also look closely at this for the dual stack bits.

review: Approve