Merge lp:~michael.nelson/charms/trusty/elasticsearch/add-ufw into lp:~charmers/charms/trusty/elasticsearch/trunk
Status: | Merged |
---|---|
Approved by: | Matt Bruzek |
Approved revision: | 38 |
Merge reported by: | Matt Bruzek |
Merged at revision: | not available |
Proposed branch: | lp:~michael.nelson/charms/trusty/elasticsearch/add-ufw |
Merge into: | lp:~charmers/charms/trusty/elasticsearch/trunk |
Diff against target: |
414 lines (+324/-3) 7 files modified
README.md (+1/-1) ansible_module_backports/ufw (+264/-0) hooks/hooks.py (+8/-1) playbook.yaml (+10/-0) tasks/install-elasticsearch.yml (+4/-1) tasks/setup-ufw.yml (+29/-0) unit_tests/test_hooks.py (+8/-0) |
To merge this branch: | bzr merge lp:~michael.nelson/charms/trusty/elasticsearch/add-ufw |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Matt Bruzek (community) | Approve | ||
Kapil Thangavelu (community) | Approve | ||
Review via email: mp+225934@code.launchpad.net |
Commit message
Firewall admin port 9200 so it's only available on the localhost or for any juju-related clients.
Description of the change
Firewall admin port 9200 so it's only available on the localhost or for any juju-related clients.
I've tested this with one of my deployments. I'll do a followup branch which firewalls the node-to-node communication port (9300) to be available only to peers.
The trusty version of ansible (1.5.2) doesn't include the ufw module, so I'm including it in the charm here (we could also grab it from the network during install, but don't want to depend on 3rd party networks). It seems like a nice way to get newer ansible functionality (modules) for our trusty charms, without having to install ansible from a ppa or similar.
ignoring expose and lack of open-port compatibility for now (es exposed publicly is bad juju). what happens on upgrade of an extant charm? afaics it will break them by installing ufw default deny mode without triggering reconsideration of the current clients. in general i've found this sort of add/one remove one pattern in response to relation events to be not ideal practice .. ie. just more complicated cause managing global state transitions and ordering, vs. just consider all the current ones and render the set / activate the delta ie a single entry point that all hooks can dispatch to.