Create an image to load schemas into the ConfigDB #61
Conversation
This file contains 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
If we want to load the schemas into the ConfigDB they cannot keep their current $ids. There is no straightforward way to resolve an $id under https://raw.githubusercontent.com into a ConfigDB entry. Create a script to be run from the Dockerfile which fixes up the schemas themselves and extracts the metadata the Manager will need later. For now give the metric schemas $ids using the urn:uuid: scheme. I'm not sure this will be the best policy going forward, as now we have both metric schemas and ConfigDB app schemas using this format; in principle there could be overlap. We could allocate a well-known metric schema base URL under factoryplus.app.amrc.co.uk, or something. In practice there won't be a problem as resolving code will always know which type of schema it's looking for. Try where possible to identify schema problems at build time. We really don't want a bad schema build getting pushed out to installations.
The Service schema has a $ref which doesn't follow the standard format. This schema is never used from within the Manager so this hasn't been picked up before.
This relies on the tidied up schema file generated by find-schemas. We can't simply call the dump-load endpoint as the ConfigDB rejects the request with 'request entity too large'. So just go one at a time.
This builds an image containing the information needed to import the schemas into the ConfigDB.
* Rename the Metric Schema app to JSON Schema. We can find usable metric schemas from the Metric Schema Info app giving name and version. * Create a Private Configuration class; the cluster manager could also use this for the bootstrap and template entries. * Push the Manager's private schemas as Private Configuration entries.
We get this from the git history. It would be possible to record author information too.
amrc-benmorrow
force-pushed
the
bmz/service-setup
branch
from
0b20366 to
d7fe50c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Create a Dockerfile which builds an image, to be run from service-setup, which loads the current set of schemas into the ConfigDB.
Schema information is loaded under two different ConfigDB Apps: one contains the actual schema, the other contains the metadata (name, version and so on) the Manager needs to display the schema selection screen.
The
$idand$reffields of the schemas are rewritten to use URLs under theurn:uuid:scheme. This URL scheme simply names a UUID without providing any address information. It will be necessary to have direct access to the schema UUID so that refs can be followed to other schemas. If necessary this can be changed to some other scheme; there are various possibilities, from a well-known scheme usingfactoryplus.app.amrc.co.ukto working out the ConfigDB URL of the schema config entry itself. But this is simpler and I think will be sufficient for now.