Merged
Conversation
To correctly have RI (referential integrity) when adding a application in 4.0, we need to know the charm metadata. This essential metadata is a requirement for things to be able to function correctly. We don't need actions, config and lxd profiles, they can be supplied when we upload the actual binary blob. As this a deeply nested struct, I'm treating it as one amorphous blob, as apposed to creating and setting each nested entity as it's own thing. The version will be the same for the whole of the metadata in it's first implementation. Although each nested type has it's own schema, so future iterations can update it independently from each other.
manadart
approved these changes
Jul 26, 2024
Member
manadart
left a comment
manadart
left a comment
There was a problem hiding this comment.
Thanks for this. I know it's grind-work.
Following on with metadata, this adds the manifest as well to help send information between the 3.6 model and a 4.0 model.
SimonRichardson
force-pushed
the
charm-metadata-manifest
branch
from
27cba10 to
d8d13b6
Compare
To ensure that we don't get name collisions on the map, expose all values. We don't need to optimise this path.
Member
Author
|
/merge |
jujubot
added a commit
that referenced
this pull request
Jul 29, 2024
…ta-manifest #148 Cherry-pick of #147 to v7, to allow landing of 3.6 without bringing in #139 We can't land this into v6 as that is for main. So effectively, v6 branch is dead and we should never have cut a release for main against v6. The main branch is unfinished and we should have been just iterating on a hash.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When migrating 3.6 to 4.0 we need to have the charm metadata and manifest upfront when importing an application. This is a requirement in order to keep RI (referential integrity) for the new SQL schema. The metadata and manifest are treated as an amorphous type, not as individual leaf types for every type of the metadata. This means when we want to rev the metadata it will be done at the root level (metadata and manifest only have a version).
Otherwise, the code is a replication of https://github.com/juju/juju/tree/main/internal/charm. Versioning of the charm will now impact model import/export. Changing the charm metadata is no longer free (probably never was, but always treated as such).
JIRA: JUJU-6411