Description

This PR implements the s3-compatible charm upload endpoint in JIMM that already existed in Juju. When uploading local charms the client 1st tries the s3-compatible endpoint then falls back to the legacy endpoint. I noticed during testing of local charm uploads with JIMM we always hit a 404 on the first try and fallback to the legacy endpoint.

In the Juju code the s3 compatible endpoint calls the same logic as the legacy endpoint so there is no real change in behaviour. The only benefit is that we mirror the same behaviour as a normal Juju controller in JIMM. See Juju's github.com/juju/juju/apiserver objectsCharmHandler.ServePut with docstring,

// ServePut serves the PUT method for the S3 API. This is the equivalent of the
// `PutObject` method in the AWS S3 API.
// Since juju's objects (S3) API only acts as a shim, this method will only
// rewrite the http request for it to be correctly processed by the legacy
// '/charms' handler.

We already have an integration test for uploading a local charm which uses the local charm client's AddLocalCharm method. This method sets up the client to first try the s3 endpoint then the legacy endpoint (see below) so we will already be testing the new endpoint alongside this change.

func NewLocalCharmClient(st base.APICallCloser) (*LocalCharmClient, error) {
	httpPutter, err := newHTTPPutter(st)
	if err != nil {
		return nil, errors.Trace(err)
	}
	s3Putter, err := newS3Putter(st)
	if err != nil {
		return nil, errors.Trace(err)
	}
	fallbackPutter, err := newFallbackPutter(s3Putter, httpPutter)
	if err != nil {
		return nil, errors.Trace(err)
	}
	frontend, backend := base.NewClientFacade(st, "Charms")
	return &LocalCharmClient{ClientFacade: frontend, facade: backend, charmPutter: fallbackPutter}, nil
}

Engineering checklist

• Documentation updated
• Covered by unit tests
• Covered by integration tests