Merge lp:~cjwatson/charms/xenial/storage/fix-nfs into lp:~stub/charms/xenial/storage/trunk
Status: | Needs review |
---|---|
Proposed branch: | lp:~cjwatson/charms/xenial/storage/fix-nfs |
Merge into: | lp:~stub/charms/xenial/storage/trunk |
Diff against target: |
121 lines (+11/-13) 8 files modified
hooks/common_util.py (+5/-6) hooks/storage-provider.d/block-storage-broker/block-storage-relation-broken (+1/-1) hooks/storage-provider.d/block-storage-broker/block-storage-relation-changed (+1/-1) hooks/storage-provider.d/local/data-relation-changed (+1/-1) hooks/storage-provider.d/nfs/config-changed (+0/-2) hooks/storage-provider.d/nfs/data-relation-changed (+1/-1) hooks/storage-provider.d/nfs/data-relation-departed (+1/-1) metadata.yaml (+1/-0) |
To merge this branch: | bzr merge lp:~cjwatson/charms/xenial/storage/fix-nfs |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Stuart Bishop | Approve | ||
Review via email: mp+360965@code.launchpad.net |
Commit message
Drop idmapd reconfiguration from nfs provider. Declare bionic support.
Description of the change
There hasn't been a NEED_IDMAPD entry in /etc/default/
I don't really know if this is the best place to send this MP, but it was the only multi-series version I could find. Merging all the disparate versions together, maybe moving them into a storage-charm project, and getting an updated and unified version into the store would be nice ...
Unmerged revisions
- 43. By Colin Watson
-
Port to Python 3.
This should be safe on >= trusty, as cloud images contain python3, and
charm-helpers will bootstrap the rest as long as the hook #! line works.I dropped unicode() from the data persistence functions, as it's
unnecessary: on Python 2 a file opened with "w" will accept str writes, and
on Python 3 json.dumps always returns str rather than bytes. - 42. By Colin Watson
-
Declare bionic support.
- 41. By Colin Watson
-
Drop idmapd reconfiguration from nfs provider.
There hasn't been a NEED_IDMAPD entry in /etc/default/
nfs-common since
at least precise (it's been unconditionally started where needed), and
so we don't need to change it or restart idmapd. Furthermore,
restarting idmapd fails as of vivid (it's called nfs-idmapd instead),
and is superseded on the client side by nfsidmap in any case.
Erm, ok.
Any bionic deployments should be using Juju storage rather than this charm as of Juju 2.5.2, after confirming lp:1783419 is fixed.
The code should move out of the charms/xenial namespace to a top level storage-charm project. That isn't your problem though, as the charm already is multi-series and in the wrong namespace. Whoever takes up maintenance of this charm can worry about that.