Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
migrations: Correct handling of local charm URLs #6901
Conversation
mjs
changed the title from
1660877 charm url migration fix
to
migrations: Correct handling of local charm URLs
Feb 2, 2017
| - Name: key, | ||
| - Counter: value, | ||
| - }) | ||
| + // The sequences for track charm revisions aren't imported |
| @@ -183,6 +184,10 @@ func streamThroughTempFile(r io.Reader) (_ io.ReadSeeker, cleanup func(), err er | ||
| } | ||
| func uploadCharms(config UploadBinariesConfig) error { | ||
| + // It is critical that charms are uploaded in ascending charm URL | ||
| + // order due to the way local charm URLs are tracked. | ||
| + utils.SortStringsNaturally(config.Charms) |
babbageclunk
Feb 2, 2017
Member
Why is this? (Reads ahead.)
I think it's so if there are multiple revisions of the same charm they're uploaded in revision order, so that the revisions are the same in the source and target? It'd be good to have that detail in the comment.
mjs
added some commits
Feb 2, 2017
|
$$merge$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Does not match ['fixes-1660877'] |
|
$$fixes-1660877$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
jujubot
merged commit 64be732
into
juju:2.1
Feb 2, 2017
mjs
deleted the
mjs:1660877-charm-url-migration-fix
branch
Feb 2, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
mjs commentedFeb 2, 2017
•
Edited 1 time
-
mjs
Feb 2, 2017
Description of change
There was a recent change to how charm URLs are tracked but migrations weren't updated to correctly support it.
Charms are now uploaded in order. This is important to ensure charm URLs are correctly assigned in the target. The charm URL used in the target is now also checked to ensure the correct value was used.
Charm revision sequences are now not directly migrated. Charm revision sequences shouldn't be explicitly set during the migration process. They get set when the charm binaries are uploaded.
QA steps
Bootstrap 2 controllers. In a model in the source controller, deploy three revisions of the same local charm. Each revision sets a slightly different status message.
Once the new units are up, confirmed that the status messages reported match their charm revisions.
Bug reference
https://bugs.launchpad.net/juju/+bug/1660877