-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Finalize pvc support #5651
Finalize pvc support #5651
Conversation
✅ Deploy Preview for knative ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
config/nav.yml
Outdated
@@ -100,6 +100,20 @@ nav: | |||
- Architecture: serving/architecture.md | |||
- Request Flow: serving/request-flow.md | |||
- Resources: | |||
- Services: |
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.
What is the idea about moving this? I (personally) do not get what why "Resources" and "Developer Topics" are two chapters in the first place. Maybe merge them all together?
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.
This was an idea coming from the other PR. Having just revisions didnt make much sense either, Services fall under the same category. I will take a look and see if we can have a better grouping but this could be something to handle in a different PR as well.
docs/serving/services/storage.md
Outdated
@@ -1,12 +1,35 @@ | |||
# Volume Support for Knative services | |||
|
|||
By default Serving supports the mounting the [volume types](https://kubernetes.io/docs/concepts/storage/volumes): `emptyDir`, `secret`, `configMap` and `projected`. [PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) are supported but require a [feature flag](../configuration/feature-flags.md) to be enabled. | |||
You can provide data storage for Knative Services by configuring different types of volumes. |
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.
four
volume types or do you see projected as another definition of the three?
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.
Actually I see them as four given that at the K8s api level we have:
Volume -> (name, VolumeSource)
VolumeSource -> {EmptyDir, Secret, ConfigMap, Projected, DownwardAPI,...}
Projected -> {DownwardAPIProjection, ConfigMapProjection, SecretProjection, ServiceAccountProjection }
Note that volumeSource DownwardAPI
is not supported directly it seems.
The last PR on this area was btw the addition of the projected downwardapi.
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.
Ah, but then the listing is a bit misleading.
different types of volumes
and in the next sentence:
volume types:
emptyDir
,secret
,configMap
andprojected
Can we change one of those "types" then?
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.
These are different type of volumes (four) according to the api. I can change to different volumes types
sounds good?
docs/serving/services/storage.md
Outdated
|
||
## Prerequisites | ||
|
||
Before you can configure PVCs for a Service, this feature must be enabled in the `KnativeServing` ConfigMap: |
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.
Do we also want to document without the operator? For the yaml install a modification of the config-map?
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.
Actually we can have a note about the operator but this is the first feature described separately, most are handled in the feature-flags page and there is no mentioning of the operator there. It is only about the config map.
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.
in the
KnativeServing
ConfigMap:
But then this is not correct, right? It is either the Custom Resource KnativeServing
or the config-features
ConfigMap.
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.
In general listing one option does not exclude the other. For completeness sake we should add both options.
So when you deploy Serving with the Operator your API is the Serving CR so config should be changed there.
Operator will propagate the change to the configmap as usual.
When you dont deploy Serving with the Operator configmap is your place where to change stuff.
I agree with describing the options available.
@ReToCode hi I updated the PR, the re-organization should de done in a follow up PR. |
docs/serving/services/storage.md
Outdated
|
||
## Prerequisites | ||
|
||
Before you can configure PVCs for a Service, this feature must be enabled in the `KnativeServing` ConfigMap: |
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.
Sorry, this is still a bit confusing
this feature must be enabled in the
KnativeServing
ConfigMap
It's either KnativeServing
CR OR the config-map
Also then the hint
Note that if you have installed Serving via the Knative operator then you need to set the above feature flags at the corresponding Serving CR.
Is unnecessary when the example is with the KnativeServing CR already.
Seems like in other pages we assume the YAML installation was used, so maybe it it easier to have a command here to patch the config-map, as we have here
kubectl patch configmap/config-network
--namespace knative-serving
--type merge
--patch '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'
Then we can also keep the note. Ideally we'll also have a section in the operator, describing the config-overwrite mechanism in general.
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.
Is unnecessary when the example is with the KnativeServing CR already.
@ReToCode the yaml file you see is not with the Serving CR it is meant to show how to modify the configmap I will use the patch just to clarify. An the reason I added this was also to note that people can either modify the configmap or the CR, anyway I will rephrase.
@ReToCode pls take a look. |
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.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ReToCode, skonto The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes #5083
Proposed Changes