-
Notifications
You must be signed in to change notification settings - Fork 8
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
[docs] Convention Server Open API spec #74
[docs] Convention Server Open API spec #74
Conversation
Signed-off-by: Jackline Mutua <[email protected]>
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.
Documenting the helpers in the webhook package is useful, the goal for #59 is to document the wire-level mechanical interface.
There are convention authors that don't want to use golang. They should be able to write a convention server in any language as long as they conform to the webhook contract. OpenAPI gives us a language independent way to describe the http request/response that the server needs to implement in order to be compatible.
The ./webhook golang package is an implementation of that contract.
Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 2 to 3. - [Release notes](https://github.com/codecov/codecov-action/releases) - [Changelog](https://github.com/codecov/codecov-action/blob/master/CHANGELOG.md) - [Commits](codecov/codecov-action@v2...v3) --- updated-dependencies: - dependency-name: codecov/codecov-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Prefixing labels is a best practice and `app.kubernetes.io/component` is a well known label. Other tools can use this label to identify resources that belong to Cartographer Conventions. Also dropping the label value namespace, so `conventions.carto.run` -> `conventions`. Signed-off-by: Scott Andrews <[email protected]>
Signed-off-by: Jackline Mutua <[email protected]>
35c830a
to
58d1dbb
Compare
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.
it's good to see this coming together
type: object | ||
properties: | ||
spec: | ||
$ref: "kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#pod-v1-core" |
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.
does this type of ref work? I know JSON Ref can use URLs, this doesn't look like a URL and Kubernetes.io would need to publish the schema for each type in open api.
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.
$ref: "kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#pod-v1-core" | |
$ref: "kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#pod-v1-core" |
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 intention was to reference the podTemplateSpec
definition from a valid kubernetes openapi spec similar to
components:
schemas:
User:
$ref: 'https://api.example.com/v2/openapi.yaml#/components/schemas/User'
fefe229
to
2ef19d8
Compare
description: specification of the desired behavior of a pod | ||
metadata: | ||
type: object | ||
properties: |
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.
there are many more possible fields https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#ObjectMeta
type: object | ||
properties: | ||
spec: | ||
type: object |
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.
there are a lot of available fields that go quite deep. Similar to the discussion about the ggcr config, we should consider leaving it open ended as to not artificially restrict new fields from being added in later versions of k8s, and not exposed by a convention server. This relates to #60
Signed-off-by: Jackline Mutua <[email protected]>
2ef19d8
to
453616b
Compare
Codecov Report
@@ Coverage Diff @@
## main #74 +/- ##
=======================================
Coverage 69.32% 69.32%
=======================================
Files 17 17
Lines 929 929
=======================================
Hits 644 644
Misses 265 265
Partials 20 20 Continue to review full report at Codecov.
|
02ee69b
to
e441912
Compare
Signed-off-by: Jackline Mutua <[email protected]>
e441912
to
026b44f
Compare
e20899e
to
79c721f
Compare
52e711d
to
1ea4260
Compare
Signed-off-by: Jackline Mutua <[email protected]>
fc59f1b
to
1096ace
Compare
Signed-off-by: Jackline Mutua <[email protected]>
1096ace
to
d06b20d
Compare
Signed-off-by: Jackline Mutua <[email protected]>
07af343
to
19979b6
Compare
Signed-off-by: Jackline Mutua <[email protected]>
19979b6
to
c3af6d0
Compare
LGTM |
Pull request
Include an Open API spec.
What this PR does / why we need it
Create a language agnostic specification on how convention authors can create convention servers.
Which issue(s) this PR fixes
Addresses issue 59