add node services URI and fields

[fmigneault]

Overview

Add node services URI and fields.

Changes

Non-breaking changes

• Node Services: Add definitions and variables for every service represented by the DACCS-Climate/Marble-node-registry.

  • Add version field using the corresponding <SERVICE>_VERSION variables.
  • Add types field restricted by specific values instead of previous keywords expected to be extendable.
  • Add <SERVICE>_IMAGE_URI variables to provide rel: service-meta link for every service.

Breaking changes

• n/a

Related Issue / Discussion

• Resolves https://github.com/bird-house/birdhouse-deploy/issues/441
• Depends on https://github.com/DACCS-Climate/Marble-node-registry/pull/40 to enforce validation

CI Operations

birdhouse_daccs_configs_branch: master birdhouse_skip_ci: false

[mishaschwartz]

@tlvu

Also, it seems all we need are additional copy/paste to make deprecated-components work so probably cheap enough to make it work as well.

Cheap enough for sure, but can we also plan to stop updating these at some point? I mean, at what point do we actually treat them as deprecated instead of just in another folder that happens to be called deprecated-components?

I guess we do not validate the value in "href", that's why we did not caught the wrong template expansion?

We are, it's just that the lnks schema uses the uri-template string type to check the href value and ${some_string_here} is a valid uri-template according to RFC6570. There's not much we can do about that.

[tlvu]

at what point do we actually treat them as deprecated instead of just in another folder that happens to be called deprecated-components?

I guess at the point where it's expensive. I agree "expensive" is very vague so up to you I guess.

[fmigneault]

I did omit flyingpigeon on purpose due to deprecated, but as highlighted, it is fairly easy to update, so I can add it as well. Will wait for a release that integrates the relevant updates to the schema to update the references.

[fmigneault]

We are, it's just that the lnks schema uses the uri-template string type to check the href value and ${some_string_here} is a valid uri-template according to RFC6570. There's not much we can do about that.

I don't think this is the cause. According to JSON-schema format is just a hint, not an enforced validation, unless otherwise specified.

jsonschema.validate("^^^!!!! <<SO NOT AN URI>> ???", {"type": "string", "format": "uri-template"})  # OK

Looking up the format check in the validator confirms this (uri and uri-template not checked):

jsonschema.draft202012_format_checker
<FormatChecker checkers=['date', 'email', 'idn-email', 'idn-hostname', 'ipv4', 'ipv6', 'regex', 'uuid']>

So, the real fix would be to add a "pattern": "^https?://" explicitly.

[mishaschwartz]

According to JSON-schema format is just a hint, not an enforced validation, unless otherwise specified.

Ok that's good to know....

[fmigneault]

run tests

[fmigneault]

For the moment, 1.2.0 still refers to keywords as only a specific set of values. Do you want to push a 1.3.0 right away with updated definitions allowing any value, and using types instead for the specific service type allowed?

[mishaschwartz]

Right, we're still discussing it here: https://github.com/DACCS-Climate/Marble-node-registry/issues/39

Ok nevermind then