-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RFC for schema requirements in cluster apps #55
Conversation
|
||
### R1: JSON Schema dialect must be specified {#r1} | ||
|
||
Each cluster app's values schema file MUST specify the schema dialect (also called draft) used via the `$schema` keyword on the top level, with the draft URI as a value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The meaning and possible values of specific keywords changed over the course of different drafts. Supporting all drafts would increase the complexity of our tooling, e.g. schemalint
. I would suggests that we initially only support the newest draft (2020-12) and add support for newer drafts as they are released.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the latest restrictions we discussed (e.g. forbid prefixItems
), does it still make sense to require 2019-09? Or can we go back to 2020-12?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if we make sure that we are indifferent to all the changes between 2019-09 and 2020-12.
That would be:
- forbid
prefixItems
(2020) - forbid
additionalItems
(2019) - forbid
items
with tuple values (2019) - forbid
$dynamicRef
and$dynamicAnchor
(2020) - forbid
$recursiveRef
and$recursiveAnchor
(2019)
As far as I know, we already wanted to forbid all of these. So we could go back to 2020-12.
Updated the draft based on suggestions. There is a new requirement R10 dealing with the |
…erging configs together with the base
This RFC has had no activity for 100 days. It will be closed in 1 week, unless activity occurs or the label |
This RFC was closed automatically because it had no activity during the week since the last message. |
This RFC was closed automatically because it had no activity during the week since the last message. |
This RFC has had no activity for 100 days. It will be closed in 1 week, unless activity occurs or the label |
This RFC was closed automatically because it had no activity during the week since the last message. |
This RFC has had no activity for 100 days. It will be closed in 1 week, unless activity occurs or the label |
This RFC was closed automatically because it had no activity during the week since the last message. |
Towards giantswarm/roadmap#1733
This RFC proposes standards (with different levels of strictness) that should at some point be met by our CAPI cluster apps (the apps defining workload clusters).