Ensure resource HTTP handlers release state

[babbageclunk]

The resource HTTP handler didn't release the state back into the state
pool - this would mean that it would stick around in the pool even after
the model was migrated away, preventing the same model from being
migrated back. (It would also leak the state if the model was destroyed.)

Thread the call to httpContext.release through so it can be called from
the right place in the resource HTTP handler.

This is the last piece of fixing https://bugs.launchpad.net/juju/+bug/1641824

QA steps:

• bootstrap 2 controllers A and B
• create model m in A
• download the Mattermost binary from https://releases.mattermost.com/3.5.1/mattermost-team-3.5.1-linux-amd64.tar.gz
• deploy Mattermost using that binary distribution
  juju deploy -m A:m cs:~cmars/mattermost --resource bdist=<path to binary distribution>
• migrate the model to b: juju migrate -c A m B
• then migrate it back: juju migrate -c B m A
• the migration should be successful

[anastasiamac]

Please also land equivalent on 2.1.
I suspect you may need to consider if it needs to be land on 2.0 as well ;D

[mjs]

Great.

[mjs]

Definitely want this in 2.1 ASAP.

[babbageclunk]

Hmm, following the QA steps didn't give me great joy. Investigating.

[babbageclunk]

!!build!!

[babbageclunk]

Do we already have something like this somewhere? It seems like we would. Where should it live if not? github.com/juju/errors?

[babbageclunk]

This is definitely not the right place for it, just wasn't sure what the right one was.

[mjs]

I haven't seen anything quite like this anywhere. The closest I've seen is something that attempts to choose the "worst" error given a set of multiple errors.

juju/errors seems like a reasonable place for this to live but given that I'm not aware of something similar elsehwhere, perhaps we haven't needed it much. I'm ok with it staying here for now.

[babbageclunk]

Ok great - next time I need it I'll move it somewhere better.

[babbageclunk]

With the latest commit repeated migration back and forth with a resource-using charm deployed works, but it's substantially gnarlier than the original changes, so it could do with rereview.

I see what you mean about the resources code, @mjs.

[babbageclunk]

Do we already have something like this somewhere? It seems like we would. Where should it live if not? github.com/juju/errors?

[babbageclunk]

This is definitely not the right place for it, just wasn't sure what the right one was.

[mjs]

I haven't seen anything quite like this anywhere. The closest I've seen is something that attempts to choose the "worst" error given a set of multiple errors.

juju/errors seems like a reasonable place for this to live but given that I'm not aware of something similar elsehwhere, perhaps we haven't needed it much. I'm ok with it staying here for now.

[babbageclunk]

Ok great - next time I need it I'll move it somewhere better.

[babbageclunk]

$$merge$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

[jujubot]

Build failed: Tests failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/9873

[babbageclunk]

Trusty tests panicked with cannot create index in statusSetterSuite.TestUnauthorized - intermittent mongo failure.

$$merge$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju